 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
name: auto-generate-gitbook
on:                                 #在master分支上进行push时触发  
  push:
    branches:
    - master

jobs:
  master-to-gh-pages:
    runs-on: ubuntu-latest
        
    steps:                          
    - name: checkout master
      uses: actions/checkout@v2
      with:
        ref: master
            
    - name: install nodejs
      uses: actions/setup-node@v1
      
    - name: configue gitbook
      run: |
        npm install -g gitbook-cli          
        gitbook install
        npm install -g gitbook-summary
                        
    - name: generate _book folder
      run: |
        book sm
        gitbook build
        cp SUMMARY.md _book
                        
    - name: push _book to branch gh-pages 
      env:
        TOKEN: ${{ secrets.ACCESS_TOKEN }}
        REF: github.com/${{github.repository}}
        MYEMAIL: chnhuangbo@qq.com                  # ！！记得修改为自己github设置的邮箱
        MYNAME: ${{github.repository_owner}}          
      run: |
        cd _book
        git config --global user.email "${MYEMAIL}"
        git config --global user.name "${MYNAME}"
        git init
        git remote add origin https://${REF}
        git add . 
        git commit -m "Updated By Github Actions With Build ${{github.run_number}} of ${{github.workflow}} For Github Pages"
        git branch -M master
        git push --force --quiet "https://${TOKEN}@${REF}" master:gh-pages        

提交代码

将仓库内代码提交到分支即可，观察仓库Actions

Reference

Gitbook+Github Pages+Github Actions

GitHub Actions 入门教程 - 阮一峰

1.1.2 - git常用操作

基本操作

用git提交代码到远程库

a.将目录切换到mobile-oss-web。cd mobile-oss-web (mac上使用命令行)

b.将修改全部提交到暂存区域。git add . //add . 表示添加全部修改。（mac上使用git命令）

c.将修改提交到当前分支。git commit －m“test” //-m后的“”里面是备注。（mac上使用git命令）

d.将代码提交到远程库。git push origin master （mac上使用git命令）

-am只是将添加到git管理的文件提交变更，与add . 和commit有区别。

查看分支

1
2
3
git branch
# 查看所有分支，包括远程
git branch -a

删除分支

1
2
3
4
# 删除本地分支
git branch -D 分支名
# 删除远程分支
git push origin --delete 分支名  # 不带remotes/origin/

拉最新代码

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
git checkout master
git pull origin master
git checkout Txxxx
git merge master
第一次提交代码
​
git checkout -b huangbo
git push origin huangbo
git branch --all
git status -s
git add .
git commit -m "test"
git push origin huangbo
本地新建分支并提交
git branch huangbo_dev
git checkout huangbo_dev
git merge master
git add .
git commit -m 'Txxx - first'
# git commtit -am T2661
git push origin huangbo_dev
​
git commit -am "update"
查看分支信息
# 列出所有本地分支
git branch
# 列出所有远程分支
git branch -r
# 列出所有本地分支和远程分支
git branch -a

拉远程分支

1
2
3
4
git fetch
# git branch -r
# git branch -a
git checkout -b 本地分支名 remotes/origin/远程分支

beta环境合并步骤

1、新建Task获取编号

a、主题：mapi-index-service下线

b、详情：mapi-index-service下线 [http://aladdin.sankuai.com/#/task/appkey/2299](http://aladdin.sankuai.com/#/task/appkey/2299)

c、分支：master

d、负责人：zhangsan

2、新建本地分支

3、提交代码到远程编号分支

4、线下发布->CI->Ligh Merge->new LightMerge

a、Base: Master;  Merge(Source Branches): 【编号】

b、CI branch：lightmerge

c、Submit...

d、Check...

e、Refresh and push

f、构建 -> 部署

线上环境/rc

1、Pullrequests

2、等待merge

3、打包

a、New Package

b、Tag: T2661-20190528   Branch:master  上线说明：=============上线周知=============

【修改内容】更换必吃菜接口依赖,支持2019必吃菜自动切榜

【影响范围】菜品spu功能

【操作】发布poi-sku-service

【负责人】xxxxx

【结对检查】xxxxx

【QA】自测

master回滚

回滚前先将git仓库所有权改成自己，关闭拒绝强制提交

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 切到master
git reset --hard HEAD^         回退到上个版本
git reset --hard HEAD~3       回退到前3次提交之前，以此类推，回退到n次提交之前
git reset --hard commit_id     退到/进到 指定commit的sha码
​
git push origin master --force
# 暂存代码
git stash
​
# 中间可以切分支创建分支
git checkout master
git checkout pull origin master
git checkout -b t1
​
git stash pop
# 强制还原成master
git reset --hard origin/master
​
# 强制覆盖远程分支，当本地分支版本比远程分支版本低时
git push origin T3456 --force
​
# 回滚代码到master
git fetch --all
git reset --hard origin/master
git pull
git push --force origin TXXX

git全局配置

修改git提交代码名称：

1
2
3
4
5
6
# 全局设置
git config --global user.email zhangsan@xxx.com
git config --global users.name bo
# 清除全局配置
git config --global --unset user.name
git config --global --unset user.email

多账号配置

参考：https://www.jianshu.com/p/89cb26e5c3e8 https://www.cnblogs.com/TRHX/p/11699999.html?ivk_sa=1024320u

配置~/.ssh/config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
Host 10.*
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Host abcd_1234
    HostName 1.2.3.4
    User zhangsan
    Port 11789
    StrictHostKeyChecking no
    IdentityFile ~/.ssh/.cloud_workspace_keys/zhangsan/abc_1639_rsa

Host github
HostName https://github.com
User chnherb
IdentityFile ~/.ssh/github_id_rsa

设置name和email

1
2
git config --global user.name "chnherb"
git config --global user.email "chnhuangbo@qq.com"

clone

1
2
3
git clone git@xxxxxx.com:chping/test.git
# 改成，===不需要修改
git clone github@xxxxxx.com:chping/test.git

报错ip节点不在known_hosts中

错误：

1
2
3
4
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '20.205.243.166'
Offending key for IP in /Users/admin/.ssh/known_hosts:12
Matching host key in /Users/admin/.ssh/known_hosts:20
Are you sure you want to continue connecting (yes/no)? yes

解决：

1
ssh-keygen -R 20.205.243.166

没有权限

1
2
# 查看信息
git config --global --list 

建仓库

git remote set-url origin ssh://git@github.com:chnherb/chnherb.github.io.git

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
echo "# myrpc" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M master
git remote add origin git@github.com:chnherb/myrpc.git
git push -u origin master

# 或已存在仓库
git remote add origin git@github.com:chnherb/myrpc.git
git branch -M master
git push -u origin master

切换/绑定仓库

git remote set-url origin ssh://git@github.com:chnherb/chnherb.github.io.git

gerrit

push代码到master

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
gerrit合并代码到master:
git branch -D master 先删除本地master
git fetch origin master:master 拉远程master 到本地
git pull origin --rebase master
git merge-base 自己的分支名 master
应该会得到一个changeId 比如bf89b70b99591e9c0d4d2a70beeda6b80049789e
git reset --soft 这个changeId bf89b70b99591e9c0d4d2a70beeda6b80049789e
git add .
git commit -m 'commitlog'
git push origin HEAD:refs/for/master 如果该步出错，按照提示敲命令，如下两条，然后再git stutas看看是否提交完，提交完则直接push
1、 gitdir=$(git rev-parse --git-dir); scp -p -P 29418 zhangsan@git.xxx.org:hooks/commit-msg ${gitdir}/hooks/
2、 git commit --amend --no-edit

报错分析

分支提交到远程分支然后

1
git push origin HEAD:refs/for/master 

报错原因： change id已经被使用

https://merrier.wang/20170820/what-is-change-id-in-git-commit.html

附没有change id：

https://www.cnblogs.com/yzhihao/p/8392704.html

合并dev冲突解决办法

tag

github tag流水线配置参考：https://github.com/chnherb/util-cli/blob/master/.github/workflows/release.yml

查看

1
2
3
4
5
6
# 查看本地所有tag
git tag # git tag -l 也可以
# 查看远程所有tag
git ls-remote --tags origin
# 查看commit tag信息
git log

创建

1
2
# 创建本地tag
git tag <tagName>   # git tag v1.0.1

推送

1
2
3
4
# 推送某个tag到远程仓库 
git push origin <tagName>
# 推送所有tag到远程仓库
git push origin --tags

删除

1
2
3
4
# 删除本地tag
git tag -d <tagName>
# 删除远程tag
git push origin :refs/tags/<tagName>

1.1.3 - git基础知识

1、git结构

git架构

Workspace：工作区
Index / Stage：暂存区
Repository：仓库区（或本地仓库）
Remote：远程仓库

2、git使用

2.1 创建git本地库

新建一个目录,将该目录转化为git本地仓库：

1
2
3
4
5
mkdir learngit #新建目录
cd learngit"
git init #将目录初始化为git仓库
# 查看git仓库状态
git status

2.2 向仓库提交文件

新建一个readme.txt文件，分两步添加该文件到Git仓库：

1
2
3
4
5
6
#新建一个文本文件
touch readme.txt 
#将新建的文件加入到缓冲区
git add readme.txt 
#将缓冲区的修改全部提交到本地仓库，-m后是对本次修改的注解
git commit -m "wrote a readme file" 

2.3 版本回退

查看历史提交的修改：

1
git log

commit后的一串字符是每次commit的id，用于检索每次提交的版本版本回退有revert和reset两种方案：

使用revert命令进行版本回退,只能回退最近一次修改版本,否则可能需要进行冲突处理，其原理是用一个相反的提交来回滚指定版本所做的修改：

1
git revert [commitid]

reset是一种重置，即错误提交了，此时要删除这个提交记录。也可以实现回滚：

1
git reset --hard [commitid]

revert和reset的比较：

1、若以上修改已经push到线上代码库, reset 删除指定commit以后,git push可能导致一大堆冲突.但是revert 并不会.

2、如果在日后现有分支和历史分支需要合并的时候,reset 恢复部分的代码依然会出现在历史分支里.但是revert 方向提交的commit 并不会出现在历史分支里.

3、reset 是在正常的commit历史中,删除了指定的commit,这时 HEAD 是向后移动了,而 revert 是在正常的commit历史中再commit一次,只不过是反向提交,他的 HEAD 是一直向前的.

2.4 文件修改

1
2
3
4
5
git diff HEAD -- [filename] #查看当前工作区和版本库里面最新版本的区别
git diff [filename] #查看工作区和暂存区的区别
git rm [filename] #删除文件
#将文件重置回上一次add或commit的状态，即取消在工作区的修改或删除
git checkout -- [filename] 

2.5 分支操作

创建新分支：

1
2
3
4
git branch [branchname] #创建新分支
git checkout [branchname] #切到新分支
git checkout -b [branchname] #创建新分支并切到新分支
git branch #查看当前分支

以上带*的表示当前所处的分支合并分支：

1
2
3
git merge --no-ff -m "merge with no-ff" [branchname] #禁用fastforward模式，保留分支记录
git merge [branchname] #将分支合并到当前分支上
git branch -d [branchname] #删除分支

分支冲突处理：当要合并的分支中有内容和master分支冲突时，需要进入该冲突的文件进行修改后重新提交

解决冲突后可以使用带参数的git log查看合并过程：

1
git log --graph --pretty=oneline --abbrev-commit

2.6 储藏工作现场

储存工作现场：

1
git stash

查看储存的工作现场：

1
git stash list

恢复工作现场：

1
2
3
git stash apply [stashid] #恢复工作现场，stashid即上面stash list显示的stash@{0}
git stash drop [stashid] #删除工作现场
git stash pop #恢复并删除工作现场

2.7 远程仓库操作

1
2
3
4
5
6
7
8
9
git remote #查看远程库信息
git remote -v #远程库详细信息
git push origin [branchname] #向远程库推送分支
#从远程库clone项目
git clone ssh://git@git.dianpingoa.com/shoppic/shoppic-service.git 
#设置本地分支与远程仓库分支的链接
git branch --set-upstream [localbranchname] origin/[remotebranchname] 
git pull # 更新代码到最新版本
git checkout -b [branchname] origin/[branchname] #从远程库抓取分支

远程操作步骤： 1、首先，可以试图用git push origin [branchname]推送自己的修改；

2、如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3、如果合并有冲突，则解决冲突，并在本地提交；

4、没有冲突或者解决掉冲突后，再用git push origin [branchname]推送就能成功！

如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

3、git常见命令

3.1 merge

git merge taget_branch

3.2 reset

一、首先解析以下这三个相关的状态和概念

1、HEAD：可以描述为当前分支最后一个提交。即本地的信息中的当前版本。

2、Index：在工作副本修改之后执行过git add操作的版本文件，可以commit了的。

3、Working Copy：工作副本是你正在修改，但是没有执行任何git操作的文件。

总的来说：

代码修改，还没做任何操作的时候就是 Working Copy，

git add * 操作之后就是Index，

git commit 之后就是HEAD。如果代码修改了之后进行git add 操作，然后git commit，那么所有三者(HEAD,INDEX(STAGING),WORKING COPY)都是相同的状态，内容相同。

二、reset

1、soft（更改HEAD）（恢复git commit的操作）

软重置。本来origin的HEAD和本地的HEAD一样，如果你指定--soft参数，Git只是单纯的把本地HEAD更改到你指定的版本那么，整个过程中，就HEAD的定义发生了变化，其他像Working Copy 和Index都没有变化。该参数用于git commit后，又要恢复还没commit的场景，重新审查代码，然后再推上去。

2、mixed(default）（恢复git add的操作，包含恢复git commit的操作）

--mixed是reset的默认参数，也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD相匹配。

3、hard（更改三者）

--hard参数将会将会重置(HEAD,INDEX(STAGING),WORKING COPY)，强制一致。该参数用于在把工作副本改成一塌糊涂的时候，包括工作副本，一股脑恢复。有些就单纯修改文件，其中有些git add了，有些git commit了，通通不管，可以一个命令恢复。

总结：

1、soft：重置git commit

2、mixed：重置git commit 和 git add

3、hard：重置git commit 和 git add 和工作副本的修改。

3.3 rebase

命令介绍

git pull --rebase

git pull的默认行为是git fetch + git merge

git pull --rebase则是git fetch + git rebase.

git fetch

从远程获取最新版本到本地，不会自动合并分支

git rebase

git rebase，顾名思义，就是重新定义（re）起点（base）的作用，即重新定义分支的版本库状态。本地更新分支节点过程如下图所示。

git_rebase01

git pull --rebase

git pull --rebase执行过程中会将本地当前分支里的每个提交(commit)取消掉，然后把将本地当前分支更新为最新的"origin"分支，该过程本地分支节点更新图如下所示：

git_rebase02

解决冲突方法

执行完git pull --rebase之后如果有合并冲突，使用以下三种方式处理这些冲突：

git rebase --abort 会放弃合并，回到rebase操作之前的状态，之前的提交的不会丢弃；

git rebase --skip 则会将引起冲突的commits丢弃掉（慎用！！）；

git rebase --continue 合并冲突，结合"git add 文件"命令一起用与修复冲突，提示开发者，一步一步地有没有解决冲突。（fix conflicts and then run "git rebase --continue"）

对上述冲突的处理

1、使用 $git rebase --abort

执行之后，本地内容会回到提交之间的状态，也就是回到以前提交但没有pull是的状态，简单来说就是撤销rebase。

2、使用 $git rebase --skip

git rebase --skip 引起冲突的commits会被丢弃，对于本文应用的例子来说开发者A对c.sh文件的commit无效，开发者A自己修改的部分全部无效，因此，在使用skip时请慎重。

执行：$ vim c.sh

查看本地c.sh文件提交内容，展示如下图所示，执行语句之后开发者A的修改无效。

3、使用 $git rebase --continue

执行完$git pull --rebase 之后，本地如果产生冲突，手动解决冲突之后，用"git add ."（注意这里可以不用commit，因为已经commit了，现在只需要调整commit的顺序而已，个人理解）命令去更新这些内容的索引(index)，然后只要执行:

$ git rebase --continue 就可以线性的连接本地分支与远程分支，无误之后就回退出，回到主分支上。

注意：一般情况下，修改后检查没问题，使用rebase continue来合并冲突。

4、提交规范

Commit message 的格式

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

1
2
3
4
5
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中Header是必须的，Body和Footer可以省略

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

1）type

type用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

（2）scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

（3）subject

subject是 commit 目的的简短描述，不超过50个字符。

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

注意：

一般提交代码标题和commit都要用header中的type
feat后用英式:，且要有空格，空格后要用小写，否则报错 Tips：

go的import要求顺序导入，可安装go fmt或者goimports，然后保存自动格式化

cmd+,选择Tools/File Watches

Reference

常用 Git 命令清单

Git教程

关于git的reset指令说明-soft、mixed、hard

git的突出解决--git rebase之abort、continue、skip

git rebase简介

彻底搞懂 Git-Rebase

约定式提交规范

commitlint+husky规范commit日志

Commit message 和 Change log 编写指南

1.2 - gitbook使用指南

gitbook

安装

1
npm install gitbook-cli -g

创建

1
2
3
mkdir hb_blog
cd hb_blog
gitbook init 

此时出现问题，按照如下解决

问题

gitbook出现TypeError: cb.apply is not a function解决办法

https://www.cnblogs.com/cyxroot/p/13754475.html

TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type string

https://xiaosongshine.blog.csdn.net/article/details/116235787

mac node版本降级

1
2
3
4
5
6
7
8
# 安装node版本管理模块n
sudo npm install n -g
# 安装稳定版
sudo n stable
# 安装最新版
sudo n latest
# 版本降级/升级
sudo n 版本号  # 如：sudo n 12.22.1

运行

1
2
3
4
5
6
7
8
# 运行
gitbook serve  
# 或 ，要求根目录有 package.json 文件
# 没有package.json文件则运行 npm init
npm run serve

# 编译
gitbook build

安装插件

插件官网

https://www.npmjs.com/

通用安装方法：

1
2
# 在book.js文件中配置好之后，直接运行
gitbook install

提前准备

book.js文件准备，在gitbook项目根目录下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
module.exports = {
    title: "chnherb's blog",
    description: "chnherb's blog about computer technology",
    author: "chnherb",
    lang: "zh-cn",
    plugins: [],
    pluginsConfig: {},
    variables: {
    },
};

搜索加强

1
2
// 项目目录下执行
npm install gitbook-plugin-search-pro

在book.js中添加

1
plugins: ["search-pro"],

代码框插件

1
npm install gitbook-plugin-code

在book.js中添加

1
plugins: ["code"],

自定义主题插件

1
npm install gitbook-plugin-theme-主题名

在book.js中添加

1
plugins: ["theme-主题名"],

菜单折叠插件

1
npm install gitbook-plugin-expandable-chapters

在book.js中添加

1
plugins: ["expandable-chapters"],

返回顶部插件

1
npm install gitbook-plugin-back-to-top-button

在book.js中添加

1
plugins: ["back-to-top-button"],

页内目录插件

1
gitbook-plugin-intopic-toc

按照文件自动生成SUMMARY

1
2
3
npm install -g gitbook-summary
# 使用
book sm # 注意md文件名不要有空格，否则目录链接失效

github配置pages

1、创建chnherb.github.io仓库

2、提交代码到 gh-pages 分支

3、在 settings->pages 中设置 Source 为 gh-pages

Reference

Gitbook+Github Pages+Github Actions

1.3 - github搜索技巧

github网页结构

网页上有项目名、更新日期、简介、贡献者、编程语言等信息

搜索技巧

in关键词搜索

关键字 in 可以搜索出 GitHub 上的资源名称 name、说明 description 和 readme 文件中的内容。description 就是 About 那一块的信息。

比如说

1
java in:name,description,readme 

其中，逗号分割表示或的意思，意思就是三者中只要有一个有 java 就行。

stars/fork数量搜索

搜索 GitHub 时用 star 数量和 fork 数量判断这个项目是否优秀的标准之一，我们可以使用大小，小于，范围等方式过滤：

1
java in:name stars:>1000 forks:>500 

表示星数大于 1000 且 forks 数大于 500，名字中含有 java 的项目。如果要指定范围，可以这样：

1
java in:name stars:5000..10000 

表示星数在 5000 到 10000 之间，名字中有 java 的项目。

按创建/更新时间搜索

按创建、更新时间搜索可以把版本老旧的资源筛选出去，比如说:

按创建时间：created:>=YYYY-MM-DD

按更新时间：pushed:>=YYYY-MM-DD

比如说搜索 2021 年之后创建的 java 项目：

1
java in:name created:>=2021-01-01 pushed:>=2021-01-01

按文件/路径内容搜索

在 GitHub 还可以按文件内容和文件路径搜索，不过有一定的限制，首先必须登录，此外项目的文件不能太多，文件不能太大，在需要搜索 fork 资源时，只能搜索到 star 数量比父级资源多的 fork 资源，并需要加上 fork:true 查询，搜索结果最多可显示同一文件的两个分段，但文件内可能有更多结果，不能使用通配符。

语法格式：

1
2
按文件内容 keyword in:file
按文件路径 keyword in:path

比如：

1
java in:file,path

按文件名、大小、扩展名搜索

语法格式如下：

1
2
3
按文件名搜索：keyword filename:FILENAME
按文件大小搜索：keyword size:>=大小
按扩展名搜索：keyword extension:EXTENSION

举个例子：

1
java filename:aaa size:>10 extension:py 

按编程语言来搜索

语法格式：

1
keyword language:LANGUAGE

比如：python language:javascript 表示搜索 javascrip 语言中关于 python 的项目。

常用搜索

1
"key word" in:name,description,readme language:java stars:>100

1.4 - 快捷键

IDE快捷键

功能	Intellij Mac	VSCode Mac	Eclipse Windows
格式化代码	cmd+opt+L	Shift+Opt+F	ctrl+shift+F
注释代码	cmd+/	cmd+/	ctrl+/
删除行	cmd+X		ctrl+D
复制行	cmd+D
接口或定义	cmd+B
具体实现	cmd+opt+B
super方法	cmd + U
上/下一个操作位置	cmd+opt+←/→	ctrl - shift ctrl -
类的层次结构	ctrl+H
方法层次结构	ctrl+shift+H
调用层次结构	ctrl+opt+H opt + F7
全局查找	cmd+shift+F
搜索方法(包括父类)	cmd+F12		Ctrl+O
查看方法被引用	alt+F7		ctrl+alt+H
查看变量被引用			ctrl+G
补全赋值	cmd+opt+v
覆盖方法（重写父类方法）	ctrl + O
实现方法（实现接口中的方法）	ctrl + I
优化import	ctrl + opt + O
最近打开的文件	cmd + E
系统设置	cmd + ,
项目结构	cmd + ;
重命名文件	shift + F6

VSCode

VSCode 格式化代码：shift+alt+F，可使用插件：IntelliJ IDEA Key Bindings

cmd+p 跳转（如文件路径+行数)

cmd+shift+p 执行命令

Mac

复制文件： Cmd + C 、Cmd + V

剪切文件: Cmd + C、Cmd + opt + V

隐藏当前程序： cmd + H

全屏： Ctrl+Cmd + F

chrome恢复关闭tab： shift+command+T

finder:显示所有文件夹 shift+cmd+. 前往任何文件夹 shift+cmd+G

alfred 剪切板

Command Alt(option) + B

截图：^ + command + A

QQ

多个QQ： command + N

eclipse mac

command + d 删除行

command + / 注释反注释

command + shift + F 格式化代码

command + option + down 复制到下一行

F3 查看定义

command + [/] 定位前/后一个访问的位置

Finder&shell

open . #从终端打开当前finder路径

Photoshop shortcuts:

cmd + D 取消选中块

scala

/usr/local/Cellar/scala/2.12.8

:q

sublime

json格式化

pretty json 格式化： cmd+ctrl+j

sublime列操作：

cmd+A

cmd+shift+L 列编辑

->

(编辑)

替换成回车 cmd+shift+enter

1.5 - hugo搭建个人网站

hugo下载&安装

hugo：https://github.com/gohugoio/hugo/releases

下载对应版本，然后解压并配置全局可用，如：

1
2
tar -zxvf hugoxxxx.tar.gz -C /Users/Bo/hugo-blog
cd /Users/Bo/hugo-blog && sudo cp hugo /usr/local/bin/

docsy

搭建步骤

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
git submodule update --init --recursive --depth 1

hugo server # 生成文件以内存方式启动
hugo server -dpublic  # 把网站临时发布到其指定的目录

HUGO_ENV=production hugo --minify --verbose
# 以当前目录启动静态服务器
cd public
python3 -m http.server 4005
python -m SimpleHTTPServer 4005

gitbook文件转换

1
2
3
4
5
6
for file in `find . -name "README.md"`
do
  newfile=`echo $file | sed 's/README.md/_index.md/g'`
  mv $file $newfile
  echo $newfile
done

增加文件头

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
for file in `find . -name "*.md"`
do
  if test -f $file
  then
    filename=${file##*/}
    filename=${filename%.*}
    echo -e """---
categories: [\"\"] 
tags: [\"\"] 
title: \"$filename\"
# linkTitle: \"\"
weight: 10
description: >
  
---\n\n$(cat $file)""" > $file
  fi
done

适配图片相对路径

1
2
3
4
for file in `find . -name "*.md"`
do
  sed -i 's#../imgs/#.../imgs/#g' $file
done

适配文件路径大小写

1
disablePathToLower = true

node版本升级

1
2
3
4
5
6
7
8
npm -v 
npm install npm@latest -g
node -v
sudo npm cache clean -f
sudo npm install -g n
sudo n stable
sudo n 8.1.2
node -v

hugo-shortcode

折叠代码

在 ./layouts/shortcodes/ 目录下新建 code.html 文件，内容如下：

1
2
3
4
5
6
{{ $_hugo_config := `{ "version": 1}` }}
{{- $codeTitle := .Get 0 -}}
<details>
    <summary>{{ $codeTitle }}</summary>
    {{.Inner}}
</details>

markdown 文件中使用代码折叠功能：

这里为了防止转义，使用了“﹛﹜” 来代替 “{}”，注意替换不要直接复制

1
2
3
﹛﹛% code 代码 %﹜﹜
  your code 
﹛﹛% /code %﹜﹜

参考博客：使用 Hugo 的 Shortcode 功能

代码滚动

1
2
3
4
5
6
<style>
pre {
  overflow-y: auto;
  max-height: 300px;
}
</style>

参考博客： https://its201.com/article/weixin_41929524/124956480 https://orianna-zzo.github.io/sci-tech/2018-08/blog%E5%85%BB%E6%88%90%E8%AE%B016-%E8%87%AA%E5%BB%BAhugo%E7%9A%84toc%E6%A8%A1%E6%9D%BF/

hugo-notice

notice 库：https://github.com/martignoni/hugo-notice

使用方法：

将 notice.html 复制到 ./layouts/shortcodes/ 目录下即可

更多详情参考：在 Hugo 博客上实践 Shortcodes 短代码

常见问题

fatal error: pipe failed

临时解决办法：

1
hugo server --watch=false

永久解决办法：

1
2
3
4
5
6
cd /Users/USER_NAME_HERE/Documents/Github/cht-docs
sudo launchctl limit maxfiles 65535 200000
ulimit -n 65535
sudo sysctl -w kern.maxfiles=100000
sudo sysctl -w kern.maxfilesperproc=65535
hugo server

更多参考：https://github.com/medic/cht-docs/issues/411

Reference

https://www.gohugo.org/

https://www.docsy.dev/docs/get-started/docsy-as-module/installation-prerequisites/

https://skyao.io/learning-hugo/docs/theme/docsy/setup.html

https://gohugo.io/content-management/syntax-highlighting/

https://zhuanlan.zhihu.com/p/98680055

https://www.gohugo.org/post/coderzh-a-hugo-pull-request/

hugo配置文件详解

Chroma Style Gallery

https://themes.gohugo.io/themes/hugo-book/

1.6 - 正则表达式

基础正则表达式速查表

字符

表达式	描述
[abc]	字符集。匹配集合中所含的任一字符。
[^abc]	否定字符集。匹配任何不在集合中的字符。
[a-z]	字符范围。匹配指定范围内的任意字符。
.	匹配除换行符以外的任何单个字符。
\|转义字符。
\w	匹配任何字母数字，包括下划线（等价于[A-Za-z0-9_]）。
\W	匹配任何非字母数字（等价于[^A-Za-z0-9_]）。
\d	数字。匹配任何数字。
\D	非数字。匹配任何非数字字符。
\s	空白。匹配任何空白字符，包括空格、制表符等。
\S	非空白。匹配任何非空白字符。

分组和引用

表达式	描述
(expression)	分组。匹配括号里的整个表达式。
(?:expression)	非捕获分组。匹配括号里的整个字符串但不获取匹配结果，拿不到分组引用。
\num	对前面所匹配分组的引用。比如(\d)\1可以匹配两个相同的数字，(Code)(Sheep)\1\2则可以匹配CodeSheepCodeSheep。

锚点/边界

表达式	描述
^	匹配字符串或行开头。
$	匹配字符串或行结尾。
\b	匹配单词边界。比如Sheep\b可以匹配CodeSheep末尾的Sheep，不能匹配CodeSheepCode中的Sheep。
\B	匹配非单词边界。比如Code\B可以匹配HelloCodeSheep中的Code，不能匹配HelloCode中的Code。

数量表示

表达式	描述
?	匹配前面的表达式0个或1个。即表示可选项。
+	匹配前面的表达式至少1个。
*	匹配前面的表达式0个或多个。
\|	或运算符。并集，可以匹配符号前后的表达式。
{m}	匹配前面的表达式m个。
{m,}	匹配前面的表达式最少m个。
{m,n}	匹配前面的表达式最少m个，最多n个。

预查断言

表达式	描述
(?=)	正向预查。比如Code(?=Sheep)能匹配CodeSheep中的Code，但不能匹配CodePig中的Code。
(?!)	正向否定预查。比如Code(?!Sheep)不能匹配CodeSheep中的Code，但能匹配CodePig中的Code。
(?<=)	反向预查。比如(?<=Code)Sheep能匹配CodeSheep中的Sheep，但不能匹配ReadSheep中的Sheep。
(?<!)	反向否定预查。比如(?<!Code)Sheep不能匹配CodeSheep中的Sheep，但能匹配ReadSheep中的Sheep。

特殊标志

表达式	描述
/.../i	忽略大小写。
/.../g	全局匹配。
/.../m	多行修饰符。用于多行匹配。

常用正则表达式

数字校验

描述	正则表达式	备注
数字	^[0-9]*$
n位数字	^\d{n}$
至少n位数字	^\d{n,}$
m~n位数字	^\d{m,n}$
整数	^(-?[1-9]\d*)$	非0开头，包括正整数和负整数
正整数	^[1-9]\d*$
负整数	^-[1-9]\d*$
非负整数	^(([1-9]\d*)\|0)$
非正整数	^((-[1-9]\d*)\|0)$
浮点数	^-?(?:[1-9]\d.\d\|0.\d[1-9]\d\|0.0+\|0)$	包括正浮点数和负浮点数
正浮点数	^(?:[1-9]\d.\d\|0.\d[1-9]\d)$
负浮点数	^-(?:[1-9]\d.\d\|0.\d[1-9]\d)$
非正浮点数	^(?:-(?:[1-9]\d.\d+\|0.\d[1-9]\d*)\|0.0+\|0)$	包含0
非负浮点数	^(?:[1-9]\d*.\d+\|0.\d+\|0.0+\|0)$	包含0
仅一位小数	^-?(?:0\|[1-9][0-9]*).[0-9]{1}$
最少一位小数	^-?(?:0\|[1-9][0-9]*).[0-9]{1,}$
最多两位小数	^-?(?:0\|[1-9][0-9]*).[0-9]{1,2}$
连续重复的数字	^(\d)\1+$	例如：111，222

字符校验

描述	正则表达式	备注
中文	^[\u4E00-\u9FA5]+$
全角字符	^[\uFF00-\uFFFF]+$
半角字符	^[\u0000-\u00FF]+$
英文字符串（大写）	^[A-Z]+$
英文字符串（小写）	^[a-z]+$
英文字符串（不区分大小写）	^[A-Za-z]+$
中文和数字	^(?:[\u4E00-\u9FA5]{0,}\|\d)+$
英文和数字	^[A-Za-z0-9]+$
数字、英文字母或者下划线组成的字符串	^\w+$
中文、英文、数字包括下划线	^[\u4E00-\u9FA5\w]+$
不含字母的字符串	^[^A-Za-z]*$
连续重复的字符串	^(.)\1+$	例如：aaa，bbb
长度为n的字符串	^.{n}$
ASCII	^[ -~]$

日期和时间校验

描述	正则表达式	备注
日期	^\d{1,4}-(?:1[0-2]\|0?[1-9])-(?:0?[1-9]\|[1-2]\d\|30\|31)$	弱校验，例如：2022-06-12
日期	^(?:(?!0000)[0-9]{4}-(?:(?:0[1-9]\|1[0-2])-(?:0[1-9]\|1[0-9]\|2[0-8])\|(?:0[13-9]\|1[0-2])-(?:29\|30)\|(?:0[13578]\|1[02])-31)\|(?:[0-9]{2}(?:0[48]\|[2468][048]\|[13579][26])\|(?:0[48]\|[2468][048]\|[13579][26])00)-02-29)$	严格校验，考虑平闰年
时间	^(?:1[0-2]\|0?[1-9]):[0-5]\d:[0-5]\d$	12小时制，例如：11:21:31
时间	^(?:[01]\d\|2[0-3]):[0-5]\d:[0-5]\d$	24小时制，例如：23:21:31
日期+时间	^(\d{1,4}-(?:1[0-2]\|0?[1-9])-(?:0?[1-9]\|[1-2]\d\|30\|31)) ((?:[01]\d\|2[0-3]):[0-5]\d:[0-5]\d)$	例如：2000-11-11 23:20:21

日常生活相关

描述	正则表达式	备注
中文名	^[\u4E00-\u9FA5·]{2,16}$
英文名	^[a-zA-Z][a-zA-Z\s]{0,20}[a-zA-Z]$
车牌号	^[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼使领][A-HJ-NP-Z][A-HJ-NP-Z0-9]{4}[A-HJ-NP-Z0-9挂学警港澳]$	不含新能源
车牌号	^[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼使领]A-HJ-NP-Z$	包含新能源
火车车次	^[GCDZTSPKXLY1-9]\d{1,4}$	例如：G1234
手机号	^(?:(?:+\|00)86)?1[3-9]\d{9}$	弱匹配
手机号	^(?:(?:+\|00)86)?1(?:(?:3[\d])\|(?:4[5-79])\|(?:5[0-35-9])\|(?:6[5-7])\|(?:7[0-8])\|(?:8[\d])\|(?:9[189]))\d{8}$	严格匹配
固话号码	^(?:(?:\d{3}-)?\d{8}\|^(?:\d{4}-)?\d{7,8})(?:-\d+)?$
手机IMEI码	^\d{15,17}$	一般是15位
邮编	^(?:0[1-7]\|1[0-356]\|2[0-7]\|3[0-6]\|4[0-7]\|5[1-7]\|6[1-7]\|7[0-5]\|8[013-6])\d{4}$	例如：211100
统一社会信用代码	^[0-9A-HJ-NPQRTUWXY]{2}\d{6}[0-9A-HJ-NPQRTUWXY]{10}$
身份证号码(1代)	^[1-9]\d{7}(?:0\d\|10\|11\|12)(?:0[1-9]\|[1-2][\d]\|30\|31)\d{3}$	15位数字
身份证号码(2代)	^[1-9]\d{5}(?:18\|19\|20)\d{2}(?:0[1-9]\|10\|11\|12)(?:0[1-9]\|[1-2]\d\|30\|31)\d{3}[0-9Xx]$	18位数字
QQ号	^[1-9][0-9]{4,}$	一般是5到10位
微信号	^[a-zA-Z][-_a-zA-Z0-9]{5,19}$	一般6~20位，字母开头，可包含字母、数字、-、_，不含特殊字符
股票代码	^(s[hz]\|S[HZ])(000[\d]{3}\|002[\d]{3}\|300[\d]{3}\|600[\d]{3}\|60[\d]{4})$	A股，例如：600519
银行卡卡号	^[1-9]{1}(?:\d{15}\|\d{18})$	一般为19位

互联网相关

描述	正则表达式	备注
域名	^[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(?:.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+$	例如：r2coding.com
网址	^(?:https?://)?[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(?:.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+$	例如：https://www.r2coding.com/
带端口号的网址(或IP)	^(?:https?://)?[\w-]+(?:.[\w-]+)+:\d{1,5}/?$	例如：http://127.0.0.1:8888/
URL	^https?://(?:www.)?[-a-zA-Z0-9@:%.+~#=]{1,256}.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()!@:%+.~#?&//=]*)$	例如：https://www.r2coding.com/#/README?id=1
邮箱email	^[A-Za-z0-9\u4e00-\u9fa5]+@[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(?:.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+$	支持中文，例如：codesheep@cs.com
用户名	^[a-zA-Z0-9_-]{4,20}$	4到20位
弱密码	^[\w]{6,16}$	6~16位，包含大小写字母和数字的组合
强密码	^.(?=.{6,})(?=.\d)(?=.[A-Z])(?=.[a-z])(?=.[!@.#$%^&? ]).*$	至少6位，包括至少1个大写字母，1个小写字母，1个数字，1个特殊字符
端口号	^(?:[0-9]\|[1-9][0-9]{1,3}\|[1-5][0-9]{4}\|6[0-4][0-9]{3}\|65[0-4][0-9]{2}\|655[0-2][0-9]\|6553[0-5])$	例如：65535
IPv4地址	^(?:(?:\d\|[1-9]\d\|1\d\d\|2[0-4]\d\|25[0-5]).){3}(?:\d\|[1-9]\d\|1\d\d\|2[0-4]\d\|25[0-5])$	例如：192.168.31.1
IPv4地址+端口	^(?:(?:\d\|[1-9]\d\|1\d\d\|2[0-4]\d\|25[0-5]).){3}(?:\d\|[1-9]\d\|1\d\d\|2[0-4]\d\|25[0-5])(?::(?:[0-9]\|[1-9][0-9]{1,3}\|[1-5][0-9]{4}\|6[0-4][0-9]{3}\|65[0-4][0-9]{2}\|655[0-2][0-9]\|6553[0-5]))?$	例如：192.168.31.1:8080
IPv6地址	^(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}\|([0-9a-fA-F]{1,4}:){1,7}:\|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}\|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}\|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}\|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}\|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}\|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})\|:((:[0-9a-fA-F]{1,4}){1,7}\|:)\|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}\|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]).){3,3}(25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9])\|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]).){3,3}(25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]))$	例如：CDCD:910A:2222:5498:8475:1111:3900:2020
IPv6地址+端口	^[(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}\|([0-9a-fA-F]{1,4}:){1,7}:\|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}\|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}\|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}\|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}\|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}\|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})\|:((:[0-9a-fA-F]{1,4}){1,7}\|:)\|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}\|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]).){3,3}(25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9])\|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]).){3,3}(25[0-5]\|(2[0-4]\|1{0,1}[0-9]){0,1}[0-9]))](?::(?:[0-9]\|[1-9][0-9]{1,3}\|[1-5][0-9]{4}\|6[0-4][0-9]{3}\|65[0-4][0-9]{2}\|655[0-2][0-9]\|6553[0-5]))?$	例如：[CDCD:910A:2222:5498:8475:1111:3900:2020]:9800
子网掩码	^(?:254\|252\|248\|240\|224\|192\|128).0.0.0\|255.(?:254\|252\|248\|240\|224\|192\|128\|0).0.0\|255.255.(?:254\|252\|248\|240\|224\|192\|128\|0).0\|255.255.255.(?:255\|254\|252\|248\|240\|224\|192\|128\|0)$	例如：255.255.255.0
MAC地址	^(?:(?:[a-f0-9A-F]{2}:){5}\|(?:[a-f0-9A-F]{2}-){5})[a-f0-9A-F]{2}$
Version版本号	^\d+(?:.\d+){2}$	例如：12.1.1
图片后缀	.(gif\|png\|jpg\|jpeg\|webp\|svg\|psd\|bmp\|tif)+	可按需增删扩展名集合
视频后缀	.(swf\|avi\|flv\|mpg\|rm\|mov\|wav\|asf\|3gp\|mkv\|rmvb\|mp4)+	可按需增删扩展名集合
图片链接	(?:https?://)?[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(?:.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+.+.(gif\|png\|jpg\|jpeg\|webp\|svg\|psd\|bmp\|tif)	可按需增删扩展名集合
视频链接	(?:https?://)?[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(?:.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+.+.(swf\|avi\|flv\|mpg\|rm\|mov\|wav\|asf\|3gp\|mkv\|rmvb\|mp4)	可按需增删扩展名集合
迅雷链接	thunderx?://[a-zA-Z\d]+=
ed2k链接	ed2k://\\|file\\|.+\\|/
磁力链接	magnet:?xt=urn:btih:[0-9a-fA-F]{40,}.*

其他

描述	正则表达式	备注
Windows文件路径	^[a-zA-Z]:(?:\[\w\u4E00-\u9FA5\s]+)+[.\w\u4E00-\u9FA5\s]+$	例如：C:\Users\Administrator\Desktop\a.txt
Windows文件夹路径	^[a-zA-Z]:(?:\[\w\u4E00-\u9FA5\s]+)+$	例如：C:\Users\Administrator\Desktop
Linux文件路径	^/(?:[^/]+/)*[^/]+$	例如：/root/library/a.txt
Linux文件夹路径	^/(?:[^/]+/)*$	例如：/root/library/
MD5格式	^(?:[a-f\d]{32}\|[A-F\d]{32})$	32位MD5，例如：7552E7071B118CBFFEC8C930455B4297
BASE64格式	^\sdata:(?:[a-z]+/[a-z0-9-+.]+(?:;[a-z-]+=[a-z0-9-]+)?)?(?:;base64)?,([a-z0-9!$&',()+;=-._~:@/?%\s]?)\s$	例如：data:image/jpeg;base64,xxxx==
UUID	^[a-f\d]{4}(?:[a-f\d]{4}-){4}[a-f\d]{12}$	例如：94f9d45a-71b0-4b3c-b69d-20c4bc9c8fdd
16进制	^[A-Fa-f0-9]+$	例如：FFFFFF
16进制颜色	^#?([0-9a-fA-F]{3}\|[0-9a-fA-F]{6})$	例如：#FFFFFF
SQL语句	^(?:select\|drop\|delete\|create\|update\|insert).*$
Java包名	^(?:[a-zA-Z_]\w)+(?:[.][a-zA-Z_]\w)+$	例如：com.r2coding.controller
文件扩展名	.(?:doc\|pdf\|txt)	可按需增删扩展名集合
HTML标签	<(\w+)[^>]>(.?</\1>)?	例如：
HTML注释		例如：

2 - OS

Introduction

操作系统，如Linux和Shell基本知识

2.1 - 00.OS相关概念

Namespace

当一台物理主机（宿主机）运行容器的时候，为了避免容器所需系统资源之间相互干扰。所以Docker利用操作系统的隔离技术-NameSpace，来实现在同一个操作系统中，不同容器之间的资源独立隔离运行。

隔离系统资源列表

Linux NameSpace是Linux系统提供的一种资源隔离机制，可实现系统资源的列表如下：

Mount	用于隔离文件系统的挂载点
UTS	用于隔离HostName和DomainName
IPC	用于隔离进程间通信
PID	用于隔离进程ID
NetWork	用于隔离网络
User	用于隔离用户和用户组 UID/GID

查看系统资源隔离

查找进程

1
ps aux | grep ssh

查看NameSpace(NS)

1
ll /proc/727 /ns/

Linux CGroup

Linux Control Group，是Linux内核的一个功能，用来限制、控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。这个项目最早是由Google的工程师在2006年发起（主要是Paul Menage和Rohit Seth），最早的名称为进程容器（process containers）。在2007年时，因为在Linux内核中，容器（container）这个名词太过广泛，为避免混乱，被重命名为cgroup，并且被合并到2.6.24版的内核中去。然后，其它开始了他的发展。

Linux CGroupCgroup 可为系统中所运行任务（进程）的用户定义组群分配资源 — 比如 CPU 时间、系统内存、网络带宽或者这些资源的组合。可以监控配置的 cgroup，拒绝 cgroup 访问某些资源，甚至在运行的系统中动态配置cgroup。

主要功能:

限制资源使用，比如内存使用上限以及文件系统的缓存限制。

优先级控制，CPU利用和磁盘IO吞吐。

一些审计或一些统计，主要目的是为了计费。

挂起进程，恢复执行进程。

cgroups子系统

1、cpu 子系统

主要限制进程的 cpu 使用率。

2、cpuacct 子系统

可以统计 cgroups 中的进程的 cpu 使用报告。

3、cpuset 子系统

可以为 cgroups 中的进程分配单独的 cpu 节点或者内存节点。

4、memory 子系统

可以限制进程的 memory 使用量。

5、blkio 子系统

可以限制进程的块设备 io。

6、devices 子系统

可以控制进程能够访问某些设备。

7、net_cls 子系统

可以标记 cgroups 中进程的网络数据包，然后可以使用 tc 模块（traffic control）对数据包进行控制。

8、net_prio

用来设计网络流量的优先级

9、freezer 子系统

可以挂起或者恢复 cgroups 中的进程。

10、ns 子系统

可以使不同 cgroups 下面的进程使用不同的 namespace

11、hugetlb

主要针对于HugeTLB系统进行限制，这是一个大页文件系统。

cgroups层级结构(Hierarchy)

内核使用 cgroup 结构体来表示一个 control group 对某一个或者某几个 cgroups 子系统的资源限制。cgroup 结构体可以组织成一颗树的形式，每一棵cgroup 结构体组成的树称之为一个 cgroups 层级结构。

cgroups层级结构可以 attach 一个或者几个 cgroups 子系统，当前层级结构可以对其 attach 的 cgroups 子系统进行资源的限制。每一个 cgroups 子系统只能被 attach 到一个 cpu 层级结构中。

创建了 cgroups 层级结构中的节点（cgroup 结构体）之后，可以把进程加入到某一个节点的控制任务列表中，一个节点的控制列表中的所有进程都会受到当前节点的资源限制。同时某一个进程也可以被加入到不同的 cgroups 层级结构的节点中，因为不同的 cgroups 层级结构可以负责不同的系统资源。所以说进程和 cgroup 结构体是一个多对多的关系。

查看系统资源限制

1
cat /proc/cgroups

CPU限制实战

查看cgroup挂载点

1
mount -t cgroup

创建隔离组

1
2
3
cd /sys/fs/cgroup/cpu  # 进入cgroup挂载点
mkdir cpu_demo # 创建目录后会自动生成文件
ls cpu_demo/ 

测试cpu

死循环程序测试cpu

1
2
3
4
5
6
int main(void) 
{
  int i=0;
  for(;;) i++;
  return 0;
}

启动程序后cpu使用100% 默认-1不限制，现在改成30000，可以理解使用率限制在30%

1
echo 30000 > /sys/fs/cgroup/cpu/cpu_demo/cpu.cfs_quota_us

找到进程号增加到cpu tasks里面，再看top cpu使用率很快就下来

1
echo <pid> >> /sys/fs/cgroup/cpu/cpu_demo/tasks

其他资源限制同cpu限制

内存限制实战

1
2
3
4
5
6
7
8
9
$ service sshd status
$ cd /sys/fs/cgroup/memory/system.slice/sshd.service
# 查看内存限制(byte)
$ cat memory.limit_in_bytes

# 设置限制内存
$ echo 64k > memory.limit_in_bytes
$ cat memory.limit_in_bytes
65536

Reference

Linux CGroup总结

https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#control-groups

https://man7.org/linux/man-pages/man7/cgroups.7.html

2.2 - Linux负载均衡LVS之IPVS

名词概念

LVS

LVS（Linux Virtual Server）即Linux虚拟服务器，是一个虚拟的服务器集群系统，由章文嵩博士在1998年5月成立，在linux2.6+后将lvs自动加入了kernel模块。

LVS的用户空间的命令行管理工具为ipvsadm，ipvs是工作在内核中netfilter的INPUT的钩子函数上，对进入的报文在没有进入用户空间前，对这些报文进行操作。

IPVS

IPVS是LVS（Linux Virtual Server）项目重要组成部分，目前包含于官方Linux Kernel，IPVS依赖于netfilter框架，位于内核源码的net/netfilter/ipvs目录下。

IPVS是LVS项目的一部分，是一款运行在Linux kernel当中的4层负载均衡器，性能异常优秀。

RS

realserver，常简称为RS

NAT

网络地址转换(Network Address Translate)

SNAT

原地址转换

DNAT

目标地址转换

几种IP

VIP

virtual IP，LVS服务器上接收外网数据包的网卡IP地址。

DIP

director IP，LVS服务器上转发数据包到realserver的网卡IP地址。

RIP

realserver(常简称为RS)上接收Director转发数据包的IP，即提供服务的服务器IP。

CIP:客户端的IP。

IPVS的三种转发模式

DR模式(Direct Routing)

DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会改写请求包的MAC地址为后端RS的MAC地址，然后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，不再经过负载均衡器。所以DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。

NAT模式(Network Address Translation)

NAT模式下，请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包做目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包做源地址转换（SNAT），将响应包的源IP改写为LB的IP。

TUN模式

采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务响应报文比请求报文大许多，采用VS/TUN技术后，调度器得到极大的解放，集群系统的最大吞吐量可以提高10倍。

FULLNAT模式

FULLNAT模式下，LB会对请求包和响应包都做SNAT+DNAT。

转发模式对比

三种转发模式性能从高到低：DR > NAT >FULLNAT。

虽然FULLNAT模式的性能比不上DR和NAT，但是FULLNAT模式没有组网要求，允许LB和RS部署在不同的子网中，这给运维带来了便利。并且 FULLNAT模式具有更好的可拓展性，可以通过增加更多的LB节点，提升系统整体的负载均衡能力。

IPVS实现Service

背景知识

一定要让Kernel认为VIP是本地地址，这样4层的LVS才能开始工作。

网络结构

步骤

1、绑定VIP到本地（欺骗内核）

1
# ip route add to local 192.168.60.200/32 dev eth0proto kernel

2、为该虚IP创建一个IPVS的virtual server

1
# ipvsadm -A -t 192.168.60.200:9376 -s rr -p 600

3、为该IPVS service创建相应的real server

1
2
3
# ipvsadm -A -t 192.168.60.200:9376 -r 10.1.2.3:80 -m
# ipvsadm -A -t 192.168.60.200:9376 -r 10.1.4.5:80 -m
# ipvsadm -A -t 192.168.60.200:9376 -r 10.1.3.8:80 -m

Reference

Linux负载均衡LVS（IPVS）

应用负载均衡之LVS(一)：基本概念和三种模式

IPVS实现Service

2.3 - shell

Introduction

shell脚本相关

2.3.1 - Shebang

简介

在计算机领域，Shebang（也称为Hashbang）是一个由井号和叹号构成的字符序列 #! ，其出现在文本文件中的第一行的前两个字符。

在文件中存在 Shebang 的情况下，类 Unix 操作系统的程序加载器会分析 Shebang 后的内容，将这些内容作为解释器指令，并调用该指令，并将载有 Shebang 的文件路径作为该解释器的参数。

例如，以指令 #!/bin/sh 开头的文件在执行时会实际调用 /bin/sh 程序。

由于 # 符号在许多脚本语言中都是注释标识符，Shebang 的内容会被这些脚本解释器自动忽略。在 # 字符不是注释标识符的语言中，例如 Scheme，解释器也可能忽略以 #! 开头的首行内容，以提供与 Shebang 的兼容性。

env bash

使用方式：

1
#!/usr/bin/env bash

env 的作用

env 命令用于显式系统中已存在的环境变量，以及在定义的环境中执行命令。

1
2
3
$ ls /usr/bin | grep env
env
printenv

与 #!/bin/bash 声明了 bash 所在位置，系统知道去哪里找 bash 相比， #!/usr/bin/env bash 只声明了 env 所在位置，然后去 $PATH 中找 bash 的位置。比如执行 env python 时，它其实会去 env | grep PATH 中的几个路径中依次寻找 python 的可执行文件。

env bash和bash对比

env bash优缺点

优点：

#!/usr/bin/env bash 不必在系统的特定位置查找命令解释器，为多系统间的移植提供了极大的灵活性和便利性（某些系统的一些命令解释器并不在 /bin 或一些约定的目录下，而是一些比较奇怪的目录）
不了解主机环境时，#!/usr/bin/env bash 可以使开发工作快速开展缺点：
对安全性比较看重时，该写法会出现安全隐患

该写法会从 $PATH 中查找命令解释器所在的位置并匹配第一个找到的位置，这意味着可以伪造一个假的命令解释器，并将伪造后的命令解释器所在目录写入 PATH 环境变量中并位于靠前位置，这样就形成了安全隐患。

因为 Shebang 解析的设计导致无法传递多个多个参数

如 #!/usr/bin/perl -w 和 #!/bin/csh -f ，而如果使用 #!/usr/bin/env perl -w 这种写法的话，perl -w 会被当成一个参数，但根本找不到 perl -w 这个命令解释器，就会出错。

某些系统 env 命令的位置不在 /usr/bin 下

bash优缺点

优点：

准确指出所需命令解释器的位置
安全性相对较高
可以传递多个参数缺点：
移植性相对较差，很多系统的命令解释器位置不一致
一些命令解释器的位置记不住

2.3.2 - curl&wget

curl

语法

1
curl [options] [URL...]

参数说明

-d/--data

参数用于发送 POST 请求的数据体。

1
2
3
4
5
6
7
curl -d'login=emma＆password=123'-X POST https://google.com/login
# 或者
curl -d 'login=emma' -d 'password=123' -X POST \
https://google.com/login

# 读取data.txt文件的内容发送
curl -d '@data.txt' https://google.com/login

1、--data value如果是@a_file_name，表示数据来自一个文件，文件中的回车符和换行符将被转换

2、--data-ascii <key=value>

完全等价于-d

--data-binary key=value

HTTP POST请求中的数据为纯二进制数据

value如果是@file_name，则保留文件中的回车符和换行符，不做任何转换

--data-raw key=value

@也作为普通字符串，不会作为文件名给出文件名的标志。即value如果是@file_name，只表示值为“@file_name”的字符串。

其他等价于-d

--data-urlencode key=value

基本同-d，区别在于会将发送的数据进行 URL 编码，如空格等

-f/--fail

禁止服务器在打开页面失败或脚本调用失败时向客户端发送错误说明，取而代之，curl 会返回错误码 22

1
2
3
# curl -fsSL https://get.docker.com | sh
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

-F/--form

模拟表单

1
2
curl -F "image=@./1.png" http:xxx     
# image 相当于<input type='file' name='image'>中name的value，@后面是文件路径

-H/--header

增加头信息

-i

打印出服务器回应的 HTTP 标头。先输出服务器回应的标头，然后空一行，再输出网页的源码。

1
curl -i https://www.example.com

-I/--head

向服务器发出 HEAD 请求，然会将服务器返回的 HTTP 标头打印出来。

1
curl -I https://www.example.com

-L/--location

让 HTTP 请求跟随服务器的重定向。curl 默认不跟随重定向。

1
curl -L -d 'tweet=hi' https://api.twitter.com/tweet

-o/--output

将服务器的回应保存成文件，等同于wget命令

1
curl -o example.html https://www.example.com

-O

服务器回应保存成文件，并将 URL 的最后部分当作文件名

1
curl -O https://www.example.com/foo/bar.html # 保存为bar.html

-p/--proxytunnel

-s

不输出错误和进度信息

1
2
curl -s https://www.example.com
curl -s -o /dev/null https://google.com

-S

参数指定只输出错误信息，通常与-o一起使用。

1
2
# 没有任何输出，除非发生错误。
curl -S -o /dev/null https://google.com

-v/--verbose

显示更多更详细的信息，调试时使用

-x

指定 HTTP 请求的代理，如果没有指定代理协议，默认为 HTTP。

1
curl -x socks5://james:cats@myproxy.com:8080 https://www.example.com

-X/--request

指定 HTTP 请求的方法

1
curl -X POST https://www.example.com

实战

连接是否可用

1
curl 10.225.147.108:9669/ping/kitex

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
curl -H "X-TT-ENV: boe_cloud_toolkits_debug_42" 10.225.147.108:9669/ping/kitex

curl --location --request POST 'https://xxx.xxx.org' \
--header 'Token: e144c79a-14e8-4908-9edf-d24e02688b36' \
--header 'X-TT-LOGID: 1234' \
--header 'Content-Type: application/json' \
--data-raw '{
    "language": "c",
    "code": "I2luY2x1ZGUgPHN0ZGlvLmg+CmludCBtYWluKCkKewogICBwcmludGYoIkhlbGxvLCBXb3JsZCBjISIpOwogICByZXR1cm4gMDsKfQ=="
}'

curl -X POST \
'http://xxx.xxx.net' \
-H 'Content-Type:application/json' \
-H 'Token:e144c79a-14e8-4908-9edf-d24e02688b36' \
-H 'X-TT-LOGID:1234567' \
--data '{"language":"c","code":"I2luY2x1ZGUgPHN0ZGlvLmg+CmludCBtYWluKCkKewogICBwcmludGYoIkhlbGxvLCBXb3JsZCBjISIpOwogICByZXR1cm4gMDsKfQ=="}'

fmt.Sprintf("curl -fsSL '%s' -o %s", downloadURL, downloadPath)

curl -i -X POST \
 -H "Content-Type:application/json" \
 -d \
'[
  {
    "type": "store",
    "key": "psmlist",
    "value": 3,
    "Tags": {
      "git": "cli",
      "username": "zhangsan"
    }
  }
]' \
'https://xxx.xxx.org/xxx'

上传文件

1
2
3
cd ${PRODUCT_OUTPUT_DIR} && curl --location --request POST \
'xxx.xxx.org/repository/xxx' \
--form "file=@\"${BUILD_REPO_PACKAGE_NAME}.tar.gz\""

获取当前机器ip

1
curl -s http://ipinfo.io/ip

wget

语法说明

参数说明

-b

后台下载

1
2
3
4
wget -b https://xxx/xxx.tar.gz
# 将把输出写入至 wget-log
# 查看下载进度
tail -f wget-log

-c/--continue

断点续传

对于我们下载大文件时突然由于网络等原因中断非常有帮助，我们可以继续接着下载而不是重新下载一个文件

-i

下载多个文件

1
2
3
4
5
6
cat > filelist.txt 
url1 
url2 
url3 
# 接着使用这个文件和参数-i下载 
wget -i filelist.txt

-reject

过滤指定格式下载

1
wget –reject=gif url   # 过滤gif图片下载某个网站

-limit-rate

设置下载速率

-o

把下载信息存入日志文件而不是显示在终端

1
wget -o download.log URL

-O/--output

下载并以不同文件名保存

下载到对应目录，并且修改文件名称

1
wget -O xxx.zip http://xxx/xxx

-q/--quiet

安静模式（无信息输出）

-Q/--quota

设置下载的容量限制

-v/--verbose

输出详细信息

实战

下载显示进度

1
wget -q --show-progress --progress=dot:mega -O targetFilePath url

下载重命名

1
wget -c -O targetFilePath url

Reference

curl用法指南

curl网站开发指南

2.3.3 - shell-find

find

文件或目录查找

1
2
3
4
5
6
# 检索当前文件夹
find .  # 同find . -print
# 检索指定文件夹
find dir
# 多个目录
find dir1 dir2

-name

按文件名搜索

1
2
3
4
5
find ./dir -name "test.txt"  # 隐藏文件 ".*"
# 模糊匹配
find ./dir -name "*.txt"
# 忽略大小写
find ./dir -iname "test.txt"

-not或!

1
2
3
4
5
find ./dir -not -name "*.txt" 
# 等同
find ./dir ! -name "*.txt"
# 多条件检索
find ./dir -name 'test' ! -name "*.txt"

-maxdepth

限制目录遍历深度

1
find ./dir -maxdepth 2

-type

文件类型

1
2
3
4
# 仅查询文件
-type f 
# 仅查询目录
-type d

-perm

访问权限

1
2
3
4
5
6
7
8
9
find ./dir --perm 0777

# 2>/dev/null 表示去掉“Permission Denied”的条目
find / -maxdepth 2 -perm /u=s 2>/dev/null

# 查找只读文件 
-perm /u=r
# 查找可执行文件 
-perm /a=x

-user

查找属于特定用户

1
find dir -user zhangsan

-group

查找属于特定组

1
find dir -group zhangsan

-time

基于修改时间的检索

1
2
3
4
# 过去N天之内修改的文件
-mtime 10  # +30 30天以前   -1 1天以内
# 过去N天之内访问的文件
-atime 10

-size

基于文件大小检索

1
2
3
4
-size 50M
# 大于xx小于xx
-size +50M -size -100M
-size +10k

高级用法

xargs

与管道一起用

1
2
# {} 替换前面的输出，"\;"固定格式
|xargs rm -rf {} \;

失效情况，不是所有情况都可以用

1
|xargs cp {} /tmp/ \;

可以换成-exec

-exec

使用范围更广（推荐），不需要管道

1
2
3
find . -name "*.txt" -exec cp -r {} /tmp/ \;
# 循环遍历当前目录下最大的5个文件
find . -type f -exec ls -s {} \; | sort -n -r | head -5

实战

将所有文件和目录都恢复成644和755

1
2
find . -type f -exec chmod -R 644 {} \;
find . -type d -exec chmod -R 755 {} \;

删除30天以前的日志

1
find . -type f -name "*.log" -mtime +30 -exec rm -rf {} \;

2.3.4 - shell文本处理三剑客

grep

grep 命令用于查找文件里符合条件的字符串。

语法

1
2
3
4
5
grep [-abcEFGhHilLnqrsvVwxy]\
[-A<显示行数>][-B<显示列数>][-C<显示列数>][-d<进行动作>]\
[-e<范本样式>][-f<范本文件>][--help][范本样式][文件或目录...]

grep "root" /etc/passwd

egrep是grep命令的扩展

-a或--text

不要忽略二进制的数据，以文本文件方式搜索

-c

计算找到符合行的次数

--color

对查找到的文本颜色标红

-n 或 --line-number

在显示符合样式的那一行之前，标示出该行的列数编号。

1
grep -n --color "root" /etc/passwd

-v或--invert-match

反向选择，显示不包含匹配文本的所有行。

-h

查询多文件时不显示文件名

-i

不区分大小写

-l

查询多文件时只输出包含匹配字符的文件名

-v

取反

-s

不显示不存在或无匹配文本的错误信息

^和$

^表示以xx字符开头，$表示以什么结尾

1
grep "^root" /etc/passwd

正则表达式

^：锚定行的开头

$：锚定行的结尾

"."：点匹配一个非换行符的字符

"*"：匹配零个或多个先前字符

".*"：一起用代表任意字符

[]：匹配一个指定范围内的字符，如"[Gg]rep"匹配Grep和grep

[^]：匹配一个不再指定范围内的字符，

{}：匹配次数，{2}表示2次，{1-3}表示1到3次

实战

前后几行

1
2
3
4
5
6
# 匹配行及后5行，不区分大小写
grep -A 5 -i foo file
# 匹配行及前5行，不区分大小写
grep -B 5 -i foo file
# 匹配行及前后5行，不区分大小写
grep -C 5 -i foo file

调试命令技巧

使用--color高亮查看grep命令的匹配结果

1
grep "[0-9][0-9]" test.txt

去除#号行内容和空行

1
grep -v "#" /usr/local/nginx/conf/nginx.conf.default | grep -v "^$"

匹配ip

1
2
3
4
5
egrep "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$" test.txt
# $表示最后最多只匹配3位数字，$表示结尾

#简化
egrep "([0-9]{1,3}\.){3}[0-9]{1,3}$" test.txt

awk

AWK 是一种处理文本文件的语言，是一个强大的文本分析工具。

语法

1
2
3
awk [选项参数] 'script' var=value file(s)
# 或
awk [选项参数] -f scriptfile var=value file(s)

-F

指定分割字符（默认以空格为分割字符）

1
2
3
4
5
6
7
8
9
# 用法
-F: 或 -F":"

# 以 : 为分割字符，打印前5行的第1列和最后1列
awk -F: '{print $1,$NF}' /etc/passwd | head -5
# 以空格分割打印

# 指定以 : 分割打印
awk -F: '{print $1":"$NF}' /etc/passwd | head -5

-v

设置变量

1
2
3
# 数字直接加，字符串拼接
awk -va=1 '{print $1,$1+a}' test.txt 
awk -va=1 -vb=s '{print $1,$1+a,$1b}' test.txt

内建变量

$n

当前记录的第n个字段，字段间由FS分隔

$0

完整记录

FS

字段分隔符(默认是任何空格)

NF

表示一行记录的个数

NR

表示文本的行数（记录数）

实战

打印第x列

默认以空格为间隔

1
2
3
4
5
6
7
8
# 打印第1列
awk '{print $1}' test.txt
# 打印第3列
awk '{print $3}' test.txt
# 打印最后1列
awk '{print $NF}' test.txt
# 打印倒数第2列
awk '{print $(NF-1)}' test.txt

打印本机ip

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# linux查找ip
ifconfig | grep "inet addr:" | grep -v "127.0.0.1" \
| awk '{print $2}' | awk -F"addr:" '{print $2}'

# 将ip的点换成-
xx接上
| awk -F. '{print $1"-"$2"-"$3"-"$4}'
# 一般机房主机名
| awk -F. '{print "xx-WEB"$1"-"$2"-"$3"-"$4".xx.net"}'

# 修改主机名，反引号表示当做一串命令执行
host `ifconfig | grep "inet addr:" | grep -v "127.0.0.1" \
| awk '{print $2}' | awk -F"addr:" '{print $2}' \
| awk -F. '{print "xx-WEB"$1"-"$2"-"$3"-"$4".xx.net"}'`

# mac查找ip
ifconfig | grep "inet " | grep -v "127.0.0.1" \
| awk '{print $2}'

sed

sed 命令是利用脚本来处理文本文件。

注意：sed里面有变量必须用双引号

语法

1
sed [-hnV][-e<script>][-f<script文件>][文本文件]

-i

修改文件内容

1
sed -i 's/old/new/2' test.txt  # 不加-i不修改文件内容

s 取代

字符替换

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
格式：
s///g 或者 s###g 

# 替换第1个old字符
sed 's/old/new/1' test.txt

# 替换第2个old字符
sed 's/old/new/2' test.txt 

# 全部替换
sed 's/old/new/g' test.txt 

1
sed -e "0,/\"name\":.*$/s//\"name\": \"$mount_docker_path\"/1" daemon.json

问题：行尾逗号比较难处理

sed参考：

https://wangchujiang.com/linux-command/c/sed.html

2.3.5 - shell解析json

背景

写一个自动安装程序的脚本，脚本需要查询接口最近的版本号从而拼接链接去下载固定的版本程序。但是之前解析json用的是jq，有一定的依赖性，虽然针对LInux没有安装jq脚本会帮忙自动安装，但是对于mac或其他平台没有做适配。鉴此，打算增加一个兜底逻辑，没有安装jq就自动解析字符串json

目标

解析json数组中第一个对象的固定字段。如下需要解析出"1.0.0.59"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
[{
        "version": "1.0.0.59",
        "arch": [
            "x86_64"
        ],
        "type": "online",
        "create_user": "zhangsan"
},
{
        "version": "1.0.0.58",
        "arch": [
            "x86_64"
        ],
        "type": "online",
        "create_user": "zhangsan"
}
]

涉及命令

sed

主要做字符替换

全局字符替换

1
sed 's/old_str/new_str/g'

grep

主要负责行查找

awk

主要做列解析

取第一行

1
awk 'NR==1'

取第一列

1
awk '{print $1}'

实战

脚本名为：parse_json.sh，文件名为json.txt

grep处理字符串和文件的区别

首先，解析出version行的内容。

grep处理多行文件和一行文件是有区别的。

获取version行命令

1
2
# echo $(cat "json.txt" | grep "version")
cat "json.txt" | grep "version"

如处理上文中多行文件输出：

1
"version": "1.0.0.59", "version": "1.0.0.58",

但如果使用以下命令将文件处理成一行：

1
echo $(cat "json.txt") > "json2.txt"

然后将执行 “获取version行命令” (修改文件名为json2.txt)

1
cat "json2.txt" | grep "version"

此时输出的是整个一行文件。问题原因：grep是按行来区分的。

如果将多行文件内容硬编码在脚本里也是当做一行处理的！！错误效果同上

sed替换,为多行

解决上面问题需要用到 sed将“,”替换成“ ”，

1
cat "json2.txt" | sed 's/,/\n/g' | grep "version"

结果依然是一行文件，原因：grep不能识别其中的换行符。

echo -e识别换行符

可以借助 echo -e 识别换行符。

1
echo -e $(cat "json2.txt" | sed 's/,/\n/g') | grep "version"

或增加中间变量，效果相同：

1
2
3
4
5
6
s1=$(echo -e $info | sed 's/,/\n/g')
# echo -e "s1:
${s1}"
# echo -e "s2:
$(echo -e $s1 | grep "version")"
echo -e $s1 | grep "version"

兼容一行或多行

不管一行多行将其先转成一行，在根据“,”转成多行

1
2
echo -e $(cat "json.txt" | sed 's/\n//g' | sed 's/,/\n/g') \
| grep "version"

这样不管文件内容如何多行或几行串在一行都不会影响最终解析结果，如1，2，3行一行，其余都是一行；或者version跟版本号不在一行等等情况。

awk取第一行

不管文件内容如何变动，执行以下命令都能稳定获取结果

1
2
3
echo -e $(cat "json.txt" | sed 's/\n//g' | sed 's/,/\n/g') \
| grep "version" \
| awk 'NR==1'

结果为：

1
[{ "version": "1.0.0.59"

sed按照:分割成两行

1
2
3
4
echo -e $(cat "json.txt" | sed 's/\n//g' | sed 's/,/\n/g') \
| grep "version" \
| awk 'NR==1' \
| sed 's/:/\n/g'

删除第一行

1
2
3
4
5
6
7
echo -e $(\
    echo -e $(cat "json.txt" | sed 's/\n//g' | sed 's/,/\n/g') \
    | grep "version" \
    | awk 'NR==1' \
    | sed 's/:/\n/g' \
    ) \
| sed '1d'

得到：

1
 "1.0.0.59"

sed去除"和空格

1
2
3
4
5
6
7
8
9
echo -e $(\
    echo -e $(cat "json.txt" | sed 's/\n//g' | sed 's/,/\n/g') \
    | grep "version" \
    | awk 'NR==1' \
    | sed 's/:/\n/g' \
    ) \
| sed '1d' \
| sed 's/"/\ /g' \
| sed 's/ //g'

得到最终结果

1
1.0.0.59

暴力测试

将json字符串任意换行（不破坏引号内字符串内容），结果都是正确的

jq解析

安装

1
2
3
4
brew install jq # 失败可以使用port安装
sudo port install jq

sudo apt-get install jq

解析json

1
2
3
4
cat "json2.txt" | jq -r '.[0].version'

echo $json_content | jq -r '.[0].version'
echo -e $json_content | jq -r '.[0].version'

tips

sed替换[

1
sed 's/[/ /g'  # 可能需要增加个空格？

2.3.6 - 获取程序当前路径有多麻烦

背景

为了实现程序自己更新自己，需要获取当前程序的安装路径。

程序执行方式

程序可以通过如下几种方式来执行：

软链接

通过软链接执行程序

1
2
3
4
5
6
7
# 生成软链接
ln -s /Users/bo/util-cli/util-cli_darwin_amd64 /usr/local/bin/util-cli

# 1、在 非/usr/local/bin路径下执行
util-cli
# 2、在/usr/local/bin路径下执行
util-cli

相对路径

如以下命令：

1
2
3
4
5
6
# 1、当前路径
./util-cli_darwin_amd64
# 2、父目录
./install_dir/util-cli_darwin_amd64
# 3、当前路径
../install_dir/util-cli_darwin_amd64

alias

通过在 .bash_profile或 .bash_rc 中配置 alias 的方式来执行

注意：脚本配置 alias 需要用 source 执行脚本而不是 bash 等，否则alias不会生效

1
alias util-cli="/Users/bo/util-cli/util-cli_darwin_amd64"

解决方案

针对以上三个类情况对文件安装目录进行解析，然后安装替换。

运行程序名称

通过os.Args[0] 来获取程序运行名称。

软链接方式

程序名称为输入的程序名称，如 util-cli

相对路径

同上，程序名称为输入的程序名称，如

1
2
3
./install_dir/util-cli_darwin_amd64
# 或
./install_dir/util-cli_darwin_amd64  # 等

alias

程序名称为文件全路径，如

1
/Users/bo/util-cli/util-cli_darwin_amd64

which/type

可通过 which type 等命令来获取其软链地址

注意：

1、which、type 不可获取 alias 地址，尤其是 sh -c which/type xxx会报错

2、程序运行时，which、type获取不到alias的别名信息，与环境有关

pwd

通过pwd或者os.Getwd()来获取当前运行路径，然后拼接运行程序名获取全路径，可解决相对路径执行方式

核心解决思路

1
ls -ld $(programName) | awk '{print $(NF)}'

该命令可解决软链在其目录下和 alias 的执行方式其他情况可搭配 which pwd 处理

程序代码

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
func getProgramRealDir(programName string) (string, error) {
   programPath, err := util.ShellExecWithWorkDir(fmt.Sprintf("ls -ld %s | awk '{print $(NF)}'", programName), ".")
   if err != nil {
      return "", err
   }
   realDir := ""
   // ln -s, not in /usr/local/bin
   if strings.HasSuffix(programPath, "No such file or directory") {
      lnCmdPath, err := util.ShellExecWithWorkDir(fmt.Sprintf("which %s", programName), ".")
      if err != nil {
         return "", err
      }
      realDir, err = util.ShellExecWithWorkDir(fmt.Sprintf("ls -ld %s | awk '{print $(NF)}'", lnCmdPath), ".")
      if err != nil {
         return "", err
      }
      return filepath.Dir(realDir), nil
   } else {
      // alias and ln -s in /usr/local/bin
      realDir = filepath.Dir(programPath)
      // relative path
      if strings.HasPrefix(programPath, ".") {
         pwd, err := os.Getwd()
         if err != nil {
            return "", nil
         }
         programDir := filepath.Dir(programPath)
         if programDir == "." {
            realDir = pwd
         } else {
            realDir = fmt.Sprintf("%s/%s", pwd, programDir)
         }
      }
   }
   return realDir, nil
}

2.4 - 进程

Introduction

进程相关

2.4.1 - Linux后台进程

背景

使用终端程序启动应用时，一旦退出命令行窗口，应用就会一起退出，无法继续运行。怎么将它变成系统的守护进程（daemon），成为一种服务（serive）？

前台/后台任务

变成守护进程的第一步，就是把它改成后台任务。

1
xxx xxx &

只要在明星的尾部加上“&”，启动的进程就会成为后台任务。如果要让前台任务变为后台任务，可以先按 ctrl + z，然后执行 bg 命令（让最近一个暂停的后台任务继续执行）。后台任务有两个特点：

1、继承当前 session 的标准输出和标准错误，因此后台任务的所有输出依然会同步地在命令行下显示

2、不再继承当前 session 的标注输入，无法向这个任务输入指令。如果它视图读取标注输入，就会暂停执行（halt）

可以看出，前台任务和后台任务的本质区别只要一个：是否继承标准输入。所以，执行后台任务的同时，用户还可以输入其他命令。

&忽略SIGINT信号

SIGHUP信号

Linux系统设计：

1、用户准备退出 session

2、系统向该 session 发出 SIGHUP 信号

3、session 将 SIGHUP 信号发给所有子进程

4、子进程收到 SIGHUP 信号后自动退出

这也解释了为什么前台任务会随着 session 的退出而退出，因为它收到 SIGHUP 信号。

那么，后台任务是否会收到 SIGHUP 信号呢？

这是由 Shell 的 huponexit 参数决定的，执行如下命令可看到该参数的值：

1
shopt | grep huponexit

大多数Linux系统，这个参数默认关闭（off），因此，session退出的时候，不会把 SIGHUP 信号发给后台任务。所以，一般后台任务不会随着session一起退出。

disown命令

通过后台任务启动守护进程并不保险，因为有的系统的 huponexit 参数可能是打开的（on）。

更保险的方法是使用 disown 命令，它可以将指定任务从**后台任务列表（jobs 命令返回的结果）**之中移除。一个后台任务只要不在这个列表中，session肯定就不会向它发出 SIGHUP 信号。

1
2
$ xxx xx &
$ disown

执行该命令后，正在执行的后台进程就被移出了后台任务列表。可以执行jobs命令验证，输出结果里面，不会有这个进程。

disown 命令使用说明

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 移出最近一个正在执行的后台任务
$ disown
# 移出所有正在执行的后台任务
$ disown -r
# 移出所有后台任务
$ disown -a
# 不移出后台任务，但是让它们不会收到SIGHUP信号
$ disown -h
# 根据jobId，移出指定的后台任务
$ disown %2
$ disown -h %2

标准I/O

使用disown命令之后，还有一个问题。那就是，退出 session 以后，如果后台进程与标准I/O有交互，它还是会挂掉。

举例，后台进程访问后有log输出。按照以下命令运行，退出session，访问进程会发现连接不上

1
2
$ xxx xx &
$ disown

这是因为后台任务的标准I/O继承自当前session，disown 命令并没有改变这一点。一旦后台任务读写标准I/O，就会发现它已经不存在，所以会报错终止执行。为了解决该问题，需要对后台任务的标准I/O进行重定向。

重定向

1
2
$ xxx xx > stdout.txt 2> stderr.txt < /dev/null &
$ disown

nohup命令

比 disown 更方便的命令，就是 nohup

1
$ nohup xxx xx &

nohup 命令对进程做了三件事 1、组织 SIGHUP 信号发到这个进程

2、关闭标准输入。该进程不再能够接收任何输入，即使运行在前台

3、重定向标准输出和标准错误到文件 nohup.out

即，nohup 命令实际上将子进程与它所在的session分离了。

注意：nohup 命令不会自动把任务变为后台任务，所以必须加上 & 符号

nohup和&比较

no hangup的缩写，意即“不挂断”

1
2
3
4
&     # ctrl+c 无影响，但是关闭 shell 程序会终止
nohup # ctrl+c 有影响，忽略SIGHUP信号，关闭 shell 程序不会终止  
nohup command & # 启动一些后台程序
# nohup java -jar xxxx.jar &

Screen/Tmux命令

Screen

另一种思路是使用 terminal multiplexer （终端复用器：在同一个终端里面，管理多个session），典型的就是 Screen 命令和 Tmux 命令。

它们可以在当前 session 里面，新建另一个 session。这样的话，当前 session 一旦结束，不影响其他 session。而且，以后重新登录，还可以再连上早先新建的 session。

Screen 的用法如下：

1
2
3
# 新建一个 session
$ screen
$ xxx xx  # 启动一个任务

然后，按下ctrl + A和ctrl + D，回到原来的 session，从那里退出登录。下次登录时，再切回去。

1
$ screen -r

如果新建多个后台 session，就需要为它们指定名字。

1
2
3
4
5
6
7
$ screen -S name
# 切回指定 session
$ screen -r name
$ screen -r pid_number

# 列出所有 session
$ screen -ls

如果要停掉某个 session，可以先切回它，然后按下ctrl + c和ctrl + d。

Tmux

Tmux 比 Screen 功能更多、更强大，它的基本用法如下。

1
2
3
4
$ tmux
$ node server.js
# 返回原来的session
$ tmux detach

除了tmux detach，另一种方法是按下Ctrl + B和d ，也可以回到原来的 session。

1
2
# 下次登录时，返回后台正在运行服务session
$ tmux attach

如果新建多个 session，就需要为每个 session 指定名字。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 新建 session
$ tmux new -s session_name

# 切换到指定 session
$ tmux attach -t session_name

# 列出所有 session
$ tmux list-sessions

# 退出当前 session，返回前一个 session 
$ tmux detach

# 杀死指定 session
$ tmux kill-session -t session-name

Node工具

对于 Node 应用来说，可以不用上面的方法，有一些专门用来启动的工具：forever，nodemon 和 pm2。

forever

forever 的功能很简单，就是保证进程退出时，应用会自动重启。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
 # 作为前台任务启动
$ forever server.js

# 作为服务进程启动 
$ forever start app.js

# 停止服务进程
$ forever stop Id

# 重启服务进程
$ forever restart Id

# 监视当前目录的文件变动，一有变动就重启
$ forever -w server.js

# -m 参数指定最多重启次数
$ forever -m 5 server.js 

# 列出所有进程
$ forever list

nodemon

nodemon一般只在开发时使用，它最大的长处在于 watch 功能，一旦文件发生变化，就自动重启进程。

1
2
3
4
5
# 默认监视当前目录的文件变化
$ nodemon server.js

＃ 监视指定文件的变化   
$ nodemon --watch app --watch libs server.js  

pm2

pm2 的功能最强大，除了重启进程以外，还能实时收集日志和监控。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 启动应用
$ pm2 start app.js

# 指定同时起多少个进程（由CPU核心数决定），组成一个集群
$ pm2 start app.js -i max

# 列出所有任务
$ pm2 list

# 停止指定任务
$ pm2 stop 0

＃ 重启指定任务
$ pm2 restart 0

# 删除指定任务
$ pm2 delete 0

# 保存当前的所有任务，以后可以恢复
$ pm2 save

# 列出每个进程的统计数据
$ pm2 monit

# 查看所有日志
$ pm2 logs

# 导出数据
$ pm2 dump

# 重启所有进程
$ pm2 kill
$ pm2 resurect

# 启动web界面 http://localhost:9615
$ pm2 web

Systemd

见 Systemd 专栏

Reference

Linux守护进程

2.4.2 - Linux的启动过程

概述

1、加载内核

操作系统接管硬件以后，首先读入 /boot 目录下的内核文件。

1
ll /boot

2、启动初始化进程

内核文件加载以后，就开始运行第一个程序 /sbin/init，它的作用是初始化系统环境。

进程编号（pid）就是1。其他所有进程都从它衍生，都是它的子进程

3、确定运行级别

许多程序需要开机启动。它们在Windows叫做"服务"（service），在Linux就叫做守护进程（daemon）。

Linux预置七种运行级别（0-6）。一般来说，0是关机，1是单用户模式（也就是维护模式），6是重启。运行级别2-5，各个发行版不太一样，对于Debian来说，都是同样的多用户模式（也就是正常模式）。

init进程首先读取文件 /etc/inittab，它是运行级别的设置文件。如果你打开它，可以看到第一行是这样的：

1
id:2:initdefault:

表明系统启动时的运行级别为2。运行级别为2的程序清单在/etc目录下面

1
2
3
4
/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
...

"rc"，表示run command（运行程序）、d表示directory（目录）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
ls /etc/rc2.d

   README
　　S01motd
　　S13rpcbind
　　S14nfs-common
　　S16binfmt-support
　　S16rsyslog
　　S16sudo
　　S17apache2
　　S18acpid
　　...

除了第一个文件README以外，其他文件名都是"字母S+两位数字+程序名"的形式。 S表示Start，K表示Kill。

如果想修改程序不建议修改该目录，可以参考：Debian Admin - Manage init 和 Debian Admin - Remove Services

4、加载开机启动程序

如果有多个运行级别的程序需要启动，为了避免拷贝，设置文件链接指向目录 /etc/init.d ，真正的启动脚本都统一放在这个目录中。init进程会运行这个目录里的启动脚本逐一加载开机启动程序。

1
2
ls -l /etc/rc2.d
# 能看到链接

另外一个好处，直接使用 /etc/init.d下的链接文件直接启动或者关闭程序，不必到真实路径下查找。如：

1
sudo /etc/init.d/apache2 restart

/etc/init.d 这个目录名最后一个字母d，表示目录（directory），用来与程序 /etc/init 区分。

5、用户登录

用户的登录方式有三种：

1）命令行登录

init进程调用getty程序（意为get teletype），让用户输入用户名和密码。输入完成后，再调用login程序，核对密码（Debian还会再多运行一个身份核对程序/etc/pam.d/login）。如果密码正确，就从文件 /etc/passwd 读取该用户指定的shell，然后启动这个shell。

2）ssh登录

这时系统调用sshd程序（Debian还会再运行/etc/pam.d/ssh ），取代getty和login，然后启动shell。

3）图形界面登录

init进程调用显示管理器，Gnome图形界面对应的显示管理器为gdm（GNOME Display Manager），然后用户输入用户名和密码。如果密码正确，就读取/etc/gdm3/Xsession，启动用户的会话。

shell就是命令行界面，让用户可以直接与操作系统对话。用户登录时打开的shell，就叫做login shell。

1）命令行登录

首先读入 /etc/profile，这是对所有用户都有效的配置；然后依次寻找下面三个文件，这是针对当前用户的配置。

1
2
3
~/.bash_profile
~/.bash_login
~/.profile

注意：这三个文件只要有一个存在，就不再读入后面的文件。 2）ssh登录：

与命令行登录完全相同。

3）图形界面登录

只加载 /etc/profile 和 ~/.profile。也就是说，~/.bash_profile 不管有没有，都不会运行。

用户进入操作系统以后，常常会再手动开启一个shell。这个shell就叫做 non-login shell，意思是它不同于登录时出现的那个shell，不读取/etc/profile和.profile等配置文件。

non-login shell 会读入用户自己的bash配置文件 ~/.bashrc。

如果不进入 non-login shell，.bashrc会通过 ~/.profile文件运行，如下.profile文件内容：

1
2
3
4
5
　　if [ -n "$BASH_VERSION" ]; then
　　　　if [ -f "$HOME/.bashrc" ]; then
　　　　　　. "$HOME/.bashrc"
　　　　fi
　　fi　　

上面代码先判断变量 $BASH_VERSION 是否有值，然后判断主目录下是否存在 .bashrc 文件，如果存在就运行该文件。第三行开头的那个点，是source命令的简写形式，表示运行某个文件，写成"source ~/.bashrc"也是可以的。因此，只要运行～/.profile文件，～/.bashrc文件就会连带运行。但是上一节的第一种情况提到过，如果存在～/.bash_profile文件，那么有可能不会运行～/.profile文件。解决这个问题很简单，把下面代码写入.bash_profile就行了。

1
2
3
　　if [ -f ~/.profile ]; then
　　　　. ~/.profile
　　fi　

这样一来，不管是哪种情况，.bashrc都会执行，用户的设置可以放心地都写入这个文件了。 Bash的设置之所以如此繁琐，是由于历史原因造成的。早期的时候，计算机运行速度很慢，载入配置文件需要很长时间，Bash的作者只好把配置文件分成了几个部分，阶段性载入。系统的通用设置放在 /etc/profile，用户个人的、需要被所有子进程继承的设置放在.profile，不需要被继承的设置放在.bashrc。

顺便提一下，除了Linux以外， Mac OS X 使用的shell也是Bash。但是，它只加载 .bash_profile，然后在.bash_profile里面调用.bashrc。而且，不管是ssh登录，还是在图形界面里启动shell窗口，都是如此。

Reference

Linux的启动过程

2.4.3 - supervisor

简介

Supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启。它是通过fork/exec的方式把这些被管理的进程当作supervisor的子进程来启动，这样只要在supervisor的配置文件中，把要管理的进程的可执行文件的路径写进去即可。也实现当子进程挂掉的时候，父进程可以准确获取子进程挂掉的信息的，可以选择是否自己启动和报警。supervisor还提供了一个功能，可以为supervisord或者每个子进程，设置一个非root的user，这个user就可以管理它对应的进程。

官网：http://supervisord.org

supervisor安装

yum源

1
yum install supervisor

Debian/Ubuntu

1
apt-get install supervisor

pip安装

1
pip install supervisor

easy_install安装

1
easy_install supervisor

supervisor使用

supervisor配置文件：/etc/supervisord.conf

注：supervisor的配置文件默认是不全的，不过在大部分默认的情况下，上面说的基本功能已经满足。

子进程配置文件路径：/etc/supervisord.d/

注：默认子进程配置文件为ini格式，可在supervisor主配置文件中修改。

配置文件说明

supervisor.conf配置文件说明

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
[unix_http_server]
file=/tmp/supervisor.sock   ;UNIX socket 文件，supervisorctl 会使用
;chmod=0700                 ;socket文件的mode，默认是0700
;chown=nobody:nogroup       ;socket文件的owner，格式：uid:gid
 
;[inet_http_server]         ;HTTP服务器，提供web管理界面
;port=127.0.0.1:9001        ;Web管理后台运行的IP和端口，如果开放到公网，需要注意安全性
;username=user              ;登录管理后台的用户名
;password=123               ;登录管理后台的密码
 
[supervisord]
logfile=/tmp/supervisord.log ;日志文件，默认是 $CWD/supervisord.log
logfile_maxbytes=50MB        ;日志文件大小，超出会rotate，默认 50MB，如果设成0，表示不限制大小
logfile_backups=10           ;日志文件保留备份数量默认10，设为0表示不备份
loglevel=info                ;日志级别，默认info，其它: debug,warn,trace
pidfile=/tmp/supervisord.pid ;pid 文件
nodaemon=false               ;是否在前台启动，默认是false，即以 daemon 的方式启动
minfds=1024                  ;可以打开的文件描述符的最小值，默认 1024
minprocs=200                 ;可以打开的进程数的最小值，默认 200
 
[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ;通过UNIX socket连接supervisord，路径与unix_http_server部分的file一致
;serverurl=http://127.0.0.1:9001 ; 通过HTTP的方式连接supervisord
 
; [program:xx]是被管理的进程配置参数，xx是进程的名称
[program:xx]
command=/opt/apache-tomcat-8.0.35/bin/catalina.sh run  ; 程序启动命令
autostart=true       ; 在supervisord启动的时候也自动启动
startsecs=10         ; 启动10秒后没有异常退出，就表示进程正常启动了，默认为1秒
autorestart=true     ; 程序退出后自动重启,可选值：[unexpected,true,false]，默认为unexpected，表示进程意外杀死后才重启
startretries=3       ; 启动失败自动重试次数，默认是3
user=tomcat          ; 用哪个用户启动进程，默认是root
priority=999         ; 进程启动优先级，默认999，值小的优先启动
redirect_stderr=true ; 把stderr重定向到stdout，默认false
stdout_logfile_maxbytes=20MB  ; stdout 日志文件大小，默认50MB
stdout_logfile_backups = 20   ; stdout 日志文件备份数，默认是10
; stdout 日志文件，需要注意当指定目录不存在时无法正常启动，所以需要手动创建目录（supervisord 会自动创建日志文件）
stdout_logfile=/opt/apache-tomcat-8.0.35/logs/catalina.out
stopasgroup=false     ;默认为false,进程被杀死时，是否向这个进程组发送stop信号，包括子进程
killasgroup=false     ;默认为false，向进程组发送kill信号，包括子进程
 
;包含其它配置文件
[include]
files = relative/directory/*.ini    ;可以指定一个或多个以.ini结束的配置文件

子进程配置文件说明

给需要管理的子进程(程序)编写一个配置文件，放在/etc/supervisor.d/目录下，以.ini作为扩展名（每个进程的配置文件都可以单独分拆也可以把相关的脚本放一起）。如任意定义一个和脚本相关的项目名称的选项组（/etc/supervisord.d/test.conf）：

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#项目名
[program:blog]
#脚本目录
directory=/opt/bin
#脚本执行命令
command=/usr/bin/python /opt/bin/test.py
#supervisor启动的时候是否随着同时启动，默认True
autostart=true
#当程序exit的时候，这个program不会自动重启,默认unexpected，设置子进程挂掉后自动重启的情况，有三个选项，false,unexpected和true。如果为false的时候，无论什么情况下，都不会被重新启动，如果为unexpected，只有当进程的退出码不在下面的exitcodes里面定义的
autorestart=false
#这个选项是子进程启动多少秒之后，此时状态如果是running，则我们认为启动成功了。默认值为1
startsecs=1
#脚本运行的用户身份 
user = test
#日志输出 
stderr_logfile=/tmp/blog_stderr.log 
stdout_logfile=/tmp/blog_stdout.log 
#把stderr重定向到stdout，默认 false
redirect_stderr = true
#stdout日志文件大小，默认 50MB
stdout_logfile_maxbytes = 20MB
#stdout日志文件备份数
stdout_logfile_backups = 20

子进程配置示例

1
2
3
4
5
6
7
8
9
#说明同上
[program:test] 
directory=/opt/bin 
command=/opt/bin/test
autostart=true 
autorestart=false 
stderr_logfile=/tmp/test_stderr.log 
stdout_logfile=/tmp/test_stdout.log 
#user = test  

supervisor命令说明

1
2
3
4
5
6
7
supervisord ctl restart serverName
supervisorctl status        //查看所有进程的状态
supervisorctl stop es       //停止es
supervisorctl start es      //启动es
supervisorctl restart       //重启es
supervisorctl update        //配置文件修改后使用该命令加载新的配置
supervisorctl reload        //重新启动配置中的所有程序

注意事项：

使用supervisor进程管理命令之前先启动supervisord，否则程序报错。

使用命令supervisord -c /etc/supervisord.conf启动。

若是centos7：

1
2
systemctl start supervisord.service     //启动supervisor并加载默认配置文件
systemctl enable supervisord.service    //将supervisor加入开机启动项

2.4.4 - systemd

背景

Linux的启动一直是采用 init 进程

如以下命令

1
2
3
$ sudo /etc/init.d/apache2 start
# 或
$ service apache2 start

该方法有如下缺点 1、启动时间长。init进程是串行启动。

2、启动脚本复杂。init进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种情况，使得脚本变得很长。

简述

Systemd 就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套完整的解决方案。

根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就是它要守护整个系统。

使用了 Systemd，就不需要再用init了。Systemd 取代了initd，成为系统的第一个进程（PID 等于 1），其他进程都是它的子进程。

Systemd 是 Linux 系统工具，用来启动守护进程，已成为大多数发行版的标准配置。

Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。与操作系统的其他部分强耦合，违反"keep simple, keep stupid"的Unix 哲学。（"简单原则"——尽量用简单的方法解决问题——是"Unix哲学"的根本原则。这也就是著名的KISS（keep it simple, stupid），意思是"保持简单和笨拙"。）

1
systemctl --version  # 查看版本

systemd架构图

系统管理

systemd不是一个命令，而是一组命令，涉及到系统管理的方方面面。

systemctl

主命令，用于管理系统。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 重启系统
$ sudo systemctl reboot
# 关闭系统，切断电源
$ sudo systemctl poweroff
# CPU停止工作
$ sudo systemctl halt
# 暂停系统
$ sudo systemctl suspend
# 让系统进入冬眠状态
$ sudo systemctl hibernate
# 让系统进入交互式休眠状态
$ sudo systemctl hybrid-sleep
# 启动进入救援状态（单用户状态）
$ sudo systemctl rescue

systemd-analyze

用于查看启动耗时。

1
2
3
4
5
6
7
8
# 查看启动耗时
$ systemd-analyze                                                                                       
# 查看每个服务的启动耗时
$ systemd-analyze blame
# 显示瀑布状的启动过程流
$ systemd-analyze critical-chain
# 显示指定服务的启动流
$ systemd-analyze critical-chain atd.service

hostnamectl

用于查看当前主机的信息。

1
2
3
4
# 显示当前主机的信息
$ hostnamectl
# 设置主机名。
$ sudo hostnamectl set-hostname rhel7

localectl

用户查看本地化设置

1
2
3
4
5
# 查看本地化设置
$ localectl
# 设置本地化参数。
$ sudo localectl set-locale LANG=en_GB.utf8
$ sudo localectl set-keymap en_GB 

timedatectl

用于查看当前时区设置

1
2
3
4
5
6
7
8
# 查看当前时区设置
$ timedatectl
# 显示所有可用的时区
$ timedatectl list-timezones                                                                                   
# 设置当前时区
$ sudo timedatectl set-timezone America/New_York
$ sudo timedatectl set-time YYYY-MM-DD
$ sudo timedatectl set-time HH:MM:SS

loginctl

用于查看当前登录的用户

1
2
3
4
5
6
# 列出当前session
$ loginctl list-sessions
# 列出当前登录用户
$ loginctl list-users
# 列出显示指定用户的信息
$ loginctl show-user ruanyf

Unit

含义

Systemd可以管理所有系统资源，不同的系统的资源统称为Unit（单位）。

Unit一共分为12种

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Service unit：系统服务
Target unit：多个 Unit 构成的一个组
Device Unit：硬件设备
Mount Unit：文件系统的挂载点
Automount Unit：自动挂载点
Path Unit：文件或路径
Scope Unit：不是由 Systemd 启动的外部进程
Slice Unit：进程组
Snapshot Unit：Systemd 快照，可以切回某个快照
Socket Unit：进程间通信的 socket
Swap Unit：swap 文件
Timer Unit：定时器

Unit查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 列出正在运行的 Unit
$ systemctl list-units
# 列出所有Unit，包括没有找到配置文件的或者启动失败的
$ systemctl list-units --all
# 列出所有没有运行的 Unit
$ systemctl list-units --all --state=inactive
# 列出所有加载失败的 Unit
$ systemctl list-units --failed
# 列出所有正在运行的、类型为 service 的 Unit
$ systemctl list-units --type=service

Unit状态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 显示系统状态
$ systemctl status
# 显示单个 Unit 的状态
$ sysystemctl status bluetooth.service
# 显示远程主机的某个 Unit 的状态
$ systemctl -H root@rhel7.example.com status httpd.service

# 查看以某个用户启动的服务
$ sudo -u <user> bash
$ systemctl --user status xxx.service  # 相关命令都需要加上--user

查询状态可以供脚本内部的判断语句使用。

1
2
3
4
5
6
# 显示某个 Unit 是否正在运行
$ systemctl is-active application.service
# 显示某个 Unit 是否处于启动失败状态
$ systemctl is-failed application.service
# 显示某个 Unit 服务是否建立了启动链接
$ systemctl is-enabled application.service

Unit管理

对于用户来说，最常用的是下面这些命令，用于启动和停止 Unit（主要是 service）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# 立即启动一个服务
$ sudo systemctl start apache.service
# 立即停止一个服务
$ sudo systemctl stop apache.service
# 重启一个服务
$ sudo systemctl restart apache.service
# 杀死一个服务的所有子进程
$ sudo systemctl kill apache.service
# 重新加载一个服务的配置文件
$ sudo systemctl reload apache.service
# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload
# 显示某个 Unit 的所有底层参数
$ systemctl show httpd.service
# 显示某个 Unit 的指定属性的值
$ systemctl show -p CPUShares httpd.service
# 设置某个 Unit 的指定属性
$ sudo systemctl set-property httpd.service CPUShares=500

Unit依赖关系

Unit 之间存在依赖关系：A 依赖于 B，就意味着 Systemd 在启动 A 的时候，同时会去启动 B。

1
2
# 查询依赖关系
$ systemctl list-dependencies nginx.service

上面命令的输出结果之中，有些依赖是 Target 类型（详见下文），默认不会展开显示。如果要展开 Target，就需要使用--all参数。

1
$ systemctl list-dependencies --all nginx.service

Unit配置文件

每个Unit都有一个配置文件，告诉Systemd怎么启动Unit。

Systemd 默认从目录/etc/systemd/system/读取配置文件。但是，里面存放的大部分文件都是符号链接，指向目录/usr/lib/systemd/system/，真正的配置文件存放在那个目录。

systemctl enable命令用于在上面两个目录之间，建立符号链接关系。

1
2
3
$ sudo systemctl enable xx.service
# 等同于
$ sudo ln -s '/usr/lib/systemd/system/xx.service' '/etc/systemd/system/xxx/xx.service'

如果配置文件里面设置了开机启动，systemctl enable命令相当于激活开机启动。与之对应的，systemctl disable命令用于在两个目录之间，撤销符号链接关系，相当于撤销开机启动。

1
$ sudo systemctl disable xx.service

配置文件的后缀名，就是该 Unit 的种类，比如sshd.socket。如果省略，Systemd 默认后缀名为.service，所以sshd会被理解成sshd.service。

配置文件状态

1
2
3
4
# 列出所有配置文件
$ systemctl list-unit-files
# 列出指定类型的配置文件
$ systemctl list-unit-files --type=service

状态一共分为四种：

1
2
3
4
enabled：已建立启动链接
disabled：没建立启动链接
static：该配置文件没有[Install]部分（无法执行），只能作为其他配置文件的依赖
masked：该配置文件被禁止建立启动链接

一旦修改配置文件，就要Systemd重新加载配置文件，然后重新启动，否则修改不会生效。

1
2
$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service

配置文件格式

配置文件为普通的文本文件。

1
2
3
4
5
6
7
8
$ systemctl cat atd.service  # 查看配置文件内容
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

配置文件分成几个区块。每个区块的第一行，是用方括号表示的区别名。每个区块内部都是一些等号连接的键值对。

注意：

1、区块名和字段名，都是大小写敏感的。

2、键值对的等号两侧不能有空格。

配置文件的区块

Unit 配置文件的完整字段清单，可以参考官方文档。

Unit区块

通常是配置文件的第一个区块。

用来定义 Unit 的元数据，以及配置与其他 Unit 的关系。主要字段如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Description：简短描述
Documentation：文档地址
Requires：当前 Unit 依赖的其他 Unit，如果它们没有运行，当前 Unit 会启动失败
Wants：与当前 Unit 配合的其他 Unit，如果它们没有运行，当前 Unit 不会启动失败
BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前 Unit 停止运行
Before：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之后启动
After：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之前启动
Conflicts：这里指定的 Unit 不能与当前 Unit 同时运行
Condition...：当前 Unit 运行必须满足的条件，否则不会运行
Assert...：当前 Unit 运行必须满足的条件，否则会报启动失败

Install区块

通常是配置文件的最后一个区块，用来定义如何启动，以及是否开启启动等。主要字段如下：

1
2
3
4
WantedBy：它的值是一个或多个 Target，当前 Unit 激活时（enable）符号链接会放入/etc/systemd/system目录下面以 Target 名 + .wants后缀构成的子目录中
RequiredBy：它的值是一个或多个 Target，当前 Unit 激活时，符号链接会放入/etc/systemd/system目录下面以 Target 名 + .required后缀构成的子目录中
Alias：当前 Unit 可用于启动的别名
Also：当前 Unit 激活（enable）时，会被同时激活的其他 Unit

Service区块

用来 Service 的配置，只有 Service 类型的 Unit 才有这个区块。主要字段如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Type：定义启动时的进程行为。它有以下几种值。
Type=simple：默认值，执行ExecStart指定的命令，启动主进程
Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出
Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行
Type=dbus：当前服务通过D-Bus启动
Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
Type=idle：若有其他任务执行完毕，当前服务才会运行
ExecStart：启动当前服务的命令
ExecStartPre：启动当前服务之前执行的命令
ExecStartPost：启动当前服务之后执行的命令
ExecReload：重启当前服务时执行的命令
ExecStop：停止当前服务时执行的命令
ExecStopPost：停止当其服务之后执行的命令
RestartSec：自动重启当前服务间隔的秒数
Restart：定义何种情况 Systemd 会自动重启当前服务，可能的值包括always（总是重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
TimeoutSec：定义 Systemd 停止当前服务之前等待的秒数
Environment：指定环境变量
KillMode: 服务停止时，杀死进程的方法

Target

启动计算机的时候，需要启动大量的 Unit。如果每一次启动，都要一一写明本次启动需要哪些 Unit，显然非常不方便。Systemd 的解决方案就是 Target。

简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于"状态点"，启动某个 Target 就好比启动到某种状态。

传统的init启动模式里面，有 RunLevel 的概念，跟 Target 的作用很类似。不同的是，RunLevel 是互斥的，不可能多个 RunLevel 同时启动，但是多个 Target 可以同时启动。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 查看当前系统的所有 Target
$ systemctl list-unit-files --type=target
# 查看一个 Target 包含的所有 Unit
$ systemctl list-dependencies multi-user.target
# 查看启动时的默认 Target
$ systemctl get-default
# 设置启动时的默认 Target
$ sudo systemctl set-default multi-user.target
# 切换 Target 时，默认不关闭前一个 Target 启动的进程，
# systemctl isolate 命令改变这种行为，
# 关闭前一个 Target 里面所有不属于后一个 Target 的进程
$ sudo systemctl isolate multi-user.target

Target 与传统 RunLevel 的对应关系如下。

1
2
3
4
5
6
7
8
Traditional runlevel      New target name     Symbolically linked to...
Runlevel 0           |    runlevel0.target -> poweroff.target
Runlevel 1           |    runlevel1.target -> rescue.target
Runlevel 2           |    runlevel2.target -> multi-user.target
Runlevel 3           |    runlevel3.target -> multi-user.target
Runlevel 4           |    runlevel4.target -> multi-user.target
Runlevel 5           |    runlevel5.target -> graphical.target
Runlevel 6           |    runlevel6.target -> reboot.target

它与init进程的主要差别如下：（1）默认的 RunLevel（在/etc/inittab文件设置）现在被默认的 Target 取代，位置是/etc/systemd/system/default.target，通常符号链接到graphical.target（图形界面）或者multi-user.target（多用户命令行）。

（2）启动脚本的位置，以前是/etc/init.d目录，符号链接到不同的 RunLevel 目录（比如/etc/rc3.d、/etc/rc5.d等），现在则存放在/lib/systemd/system和/etc/systemd/system目录。

（3）配置文件的位置，以前init进程的配置文件是/etc/inittab，各种服务的配置文件存放在/etc/sysconfig目录。现在的配置文件主要存放在/lib/systemd目录，在/etc/systemd目录里面的修改可以覆盖原始设置。

日志管理

Systemd 统一管理所有 Unit 的启动日志。带来的好处就是，可以只用journalctl一个命令，查看所有日志（内核日志和应用日志）。日志的配置文件是/etc/systemd/journald.conf。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
# 查看所有日志（默认情况下 ，只保存本次启动的日志）
$ sudo journalctl
# 查看内核日志（不显示应用日志）
$ sudo journalctl -k
# 查看系统本次启动的日志
$ sudo journalctl -b
$ sudo journalctl -b -0
# 查看上一次启动的日志（需更改设置）
$ sudo journalctl -b -1
# 查看指定时间的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"
# 显示尾部的最新10行日志
$ sudo journalctl -n
# 显示尾部指定行数的日志
$ sudo journalctl -n 20
# 实时滚动显示最新日志
$ sudo journalctl -f
# 查看指定服务的日志
$ sudo journalctl /usr/lib/systemd/systemd
# 查看指定进程的日志
$ sudo journalctl _PID=1
# 查看某个路径的脚本的日志
$ sudo journalctl /usr/bin/bash
# 查看指定用户的日志
$ sudo journalctl _UID=33 --since today
# 查看某个 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today
# 实时滚动显示某个 Unit 的最新日志
$ sudo journalctl -u nginx.service -f
# 合并显示多个 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today
# 查看指定优先级（及其以上级别）的日志，共有8级
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b
# 日志默认分页输出，--no-pager 改为正常的标准输出
$ sudo journalctl --no-pager
# 以 JSON 格式（单行）输出
$ sudo journalctl -b -u nginx.service -o json
# 以 JSON 格式（多行）输出，可读性更好
$ sudo journalctl -b -u nginx.serviceqq
 -o json-pretty
# 显示日志占据的硬盘空间
$ sudo journalctl --disk-usage
# 指定日志文件占据的最大空间
$ sudo journalctl --vacuum-size=1G
# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years

Reference

Linux下service xxx服务深入理解

使用systemd管理程序

2.4.5 - goreman

概述

Linux下多进程管理工具对开发和运维都很有用，常见的功能全面的主流工具主要有monit、supervisor。不过开发中使用则推荐轻量级小工具 goreman。

goreman 是对 Ruby 下广泛使用的 foreman 的重写，毕竟基于golang的工具简单易用很多。

goreman的作者是mattn，在golang社区挺活跃的日本的一名程序员。foreman原作者也实现了一个golang版：forego，不过没有goreman好用，举个例子：coreos的etcd就是使用的goreman来一键启停单机版的etcd集群。

安装

前提：
先安装好 go 环境
将 $GOPATH/bin 添加到 $PATH

go 工具安装都比较简单：

1
2
3
4
go get github.com/mattn/goreman
# 或
go install github.com/mattn/goreman@latest
goreman help

使用

善用 goreman help

新建一个 Procfile 文件，如果改名则需要 goreman -f 指定
在包含 Procfile 的目录下执行： goreman start
关闭时直接 ctrl + c 退出，goreman 会自动把所有启动的进程都 shut down

举例

kafka

以 Apache kafka 的使用为例，了解的朋友应该知道，kafka 使用时通常需要启动两个进程：zookeeper 和 kafka broker，因此可以编写一个 kafka 开发环境的 Procfile：

1
2
zookeeper: bash ~/tool/kafka_2.11-0.8.2.1/bin/zookeeper-server-start.sh config/zookeeper.properties
broker: bash ~/tool/kafka_2.11-0.8.2.1/bin/kafka-server-start.sh config/server.properties

然后执行 goreman start ，可以看到不同颜色区分的 zookeeper、kafka broker 进程的启动日志。关闭时，直接 ctrl + c，则两个 bash 进程也会被自动关闭。

etcd raftexample

1
2
3
4
# Use goreman to run `go install github.com/mattn/goreman@latest`
raftexample1: ./raftexample --id 1 --cluster http://127.0.0.1:12379,http://127.0.0.1:22379,http://127.0.0.1:32379 --port 12380
raftexample2: ./raftexample --id 2 --cluster http://127.0.0.1:12379,http://127.0.0.1:22379,http://127.0.0.1:32379 --port 22380
raftexample3: ./raftexample --id 3 --cluster http://127.0.0.1:12379,http://127.0.0.1:22379,http://127.0.0.1:32379 --port 32380

高级用法

上述是最简单的使用场景：直接使用 goreman start，不过有个缺点，即 goreman 绑定到了当前的 session，而且不能灵活控制多个进程启停以及顺序。而实际开发过程中，通常需要经常单独启停某个正在开发的模块相关的进程，比如上面例子中的 kafka-broker，而 Zookeeper 通常不需要频繁启停。

可以使用更高级的 goreman run 命令来实现，如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 先启动 Zookeeper
goreman run start zookeeper
# 然后启动 kafka
goreman run start broker
# 查看进程状态
goreman run status
# 停止 broker 进程
goreman run stop broker
# 重启 broker 进程
goreman run restart broker

小结

多进程管理是目前开发尤其是互联网web、服务器后端很常用的工具，尤其上云之后，云应用普遍推崇的 microservices 微服务架构进一步增加了后端进程数。而 goreman 很适合开发环境使用，能够一键式管理多个后台进程，并及时清理环境。不过真正的生产环境，还是使用monit/m、supervisor 等更成熟稳定、功能全面的多进程管理工具。

2.4.6 - 守护进程

简述

守护进程（daemon）是生存期长的一种进程，没有控制终端。它们常常在系统引导装入时启动，仅在系统关闭时才终止。UNIX系统有很多守护进程，守护进程程序的名称通常以字母“d”结尾：例如，syslogd 就是指管理系统日志的守护进程。通过ps进程查看器 ps -efj 的输出实例，内核守护进程的名字出现在方括号中，大致输出如下：

基本概念

进程组

每个进程除了有一个进程ID之外，还属于一个进程组
进程组是一个或多个进程的集合，同一进程组中的各进程接收来自同一终端的各种信号
每个进程组有一个组长进程。组长进程的进程组ID等于其进程ID

会话（session）是一个或多个进程组的集合，进程调用 setsid 函数（原型：pid_t setsid(void) ）建立一个会话。

进程调用 setsid 函数建立一个新会话，如果调用此函数的进程不是一个进程组的组长，则此函数创建一个新会话。具体会发生以下3件事：

该进程变成新会话的会话首进程（session leader，会话首进程是创建该会话的进程）。此时，该进程是新会话的唯一进程。
该进程成为一个新进程组的组长进程。新进程组ID是该调用进程的进程ID
该进程没有控制终端。如果调用setsid之前该进程有一个控制终端，那么这种联系也被切断

控制终端（Controlling Terminal）

每个会话可以有一个单独的控制终端，与控制终端连接的 Leader 就是控制进程（Controlling Process）。

进程分类

子进程child thread：

相对父进程而言，父进程创建的进程，子进程只能对应一个父进程。如果没有标记为daemon ，则杀死父进程不会对子进程的运行状态有丝毫影响。

守护进程daemon thread：

即daemon thread，是子进程的一种状态，标记子进程与父进程一起结束。

僵尸进程：

本该结束，但仍在后台运行的子进程。因为某些子进程没有设置daemon 属性，如果杀死父进程，其子进程将会变成“僵尸进程”。僵尸进程的父进程将成为init 进程的子进程。

基本操作

查看守护进程

1
2
3
4
ps -axj
-a表示显示由其他用户所拥有的进程的状态
-x显示没有控制终端的进程状态
-j显示与作业有关的信息：会话ID、进程组ID等 

如何编写守护进程

可参考《unix环境高级编程》第13章守护进程

如何使普通进程达到守护进程的部分效果

参考 Linux后台进程专栏

1
nohup ./a.out &

nohup忽略SIGHUP信号，&忽略SIGINT信号。

守护进程的创建

fork

守护进程的父进程是 init 进程，在创建时先从父进程 fork 出来一个子进程，退出父进程，这时子进程变成孤儿，就成了 init 的子进程。

子进程会继承父进程的会话，进程组，控制终端，文件描述符等。

setid

通过setid()来创建新会话，同时也脱离了原来的进程组，会话以及控制终端，成为新的会话的组长。此时它可能会再申请一个控制终端，所以我们再 fork 一下，并只保留新的子进程，这样就不是会话组长了，就不能申请控制终端了。

close(fd)

之后再关闭从父进程继承的文件描述符。至少要关闭 0,1,2 这三个文件描述符，分别对应了 stdin, stdout, 和 stderr。不过通常用 sysconf(_SC_OPEN_MAX) 获取系统允许的最大文件描述符个数，然后全部 close 掉。

关闭之后我们要将文件描述符 0，1，2 重新定向到 "/dev/null"，防止新打开的文件的文件描述符为 0，1，2。

umask(0)

设置文件掩码是为了不受父进程的 umask 的影响，能自由创建读写文件和目录。

chdir("/")

守护进程一般是一直执行到系统关机，在它运行过程中，它所在的目录就不能卸载（unmounted）。通过将它的工作目录转移到根目录，用来的目录就允许卸载了。也不一定要根目录（这种情况，运行需要超级权限），可以选择一个不需要卸载的路径。

对比

守护进程与后台进程的区别

1、守护进程已经完全脱离终端控制台了，而后台程序并未完全脱离终端(在终端未关闭前还是会往终端输出结果);

2、守护进程在关闭终端控制台时不会受影响，而后台程序会随用户退出而停止，需要在启动命令后加上“&”格式运行才能避免影响;

3、守护进程的会话组和当前目录、文件描述符都是独立的。后台进程运行只是终端进行了一次fork，仅仅让程序在后台执行而已。

Reference

守护进程（Daemon）

2.4.7 - 进程间通信

简述

IPC（Inter-Process Communication，进程间通信）。进程间通信是指两个进程的数据之间产生交互

进程间通信方式

有如下几种方式：

管道/匿名管道(pipe)
命名管道(FIFO)
消息队列
共享内存
信号量
信号
套接字

管道/匿名管道(pipe)

匿名管道（Anonymous Pipes），即将多个命令串起来的竖线，背后的原理到底是什么。

如

1
ps -ef |grep xxx |awk '{print $2}'|xargs kill -9

创建管道，系统调用

1
int pipe(int fd[2])

创建管道 pipe，返回了两个文件描述符，表示管道的两端，一个是管道的读取端描述符 fd[0]，另一个是管道的写入端描述符 fd[1]。

所谓的匿名管道，其实就是内核里面的一串缓存。

无论是匿名管道，还是命名管道，在内核都是一个文件。只要是文件就要有一个 inode。这里又用到了特殊 inode、字符设备、块设备，其实都是这种特殊的 inode。

在这种特殊的 inode 里面，file_operations 指向管道特殊的 pipefifo_fops，这个 inode 对应内存里面的缓存。

当用文件的 open 函数打开这个管道设备文件的时候，会调用 pipefifo_fops 里面的方法创建 struct file 结构，inode 指向特殊的 inode，也对应内存里面的缓存，file_operations 也指向管道特殊的 pipefifo_fops。

写入一个 pipe 就是从 struct file 结构找到缓存写入，读取一个 pipe 就是从 struct file 结构找到缓存读出。

命名管道(FIFO)

通过 mkdifo 命令显示创建

1
2
3
4
$ mkfifo hello_pipe
$ ls -l 
prw-r--r-- 1 root root 0 May 21 23:29 hello_pipe
# 文件类型 p，表示 pipe

测试

1
2
3
4
5
6
# 终端1
echo "hello world" > hello_pipe # 阻塞

# 终端2
$ echo < hello_pipe # 终端1 命令退出
hello world 

消息队列

结构体

1
2
3
4
struct msg_buffer {
    long mtype;
    char mtext[1024];
};

创建消息队列

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <stdio.h>
#include <stdlib.h>
#include <sys/msg.h>

int main() {
  int messagequeueid;
  key_t key;



  if((key = ftok("/root/messagequeue/messagequeuekey", 1024)) < 0)
  {
      perror("ftok error");
      exit(1);
  }

  printf("Message Queue key: %d.
", key);

  if ((messagequeueid = msgget(key, IPC_CREAT|0777)) == -1)
  {
      perror("msgget error");
      exit(1);
  }

  printf("Message queue id: %d.
", messagequeueid);
}

运行上面的程序

1
2
3
$ ./a.out
Message Queue key: 92536.
Message queue id: 32768.

msgget 函数； ftok（file to key）会根据文件的 inode 生成近乎唯一的 key。

这些都属于 System V IPC 进程间通信机制体系。

System V IPC 体系有一个统一的命令行工具：ipcmk，ipcs 和 ipcrm 用于创建、查看和删除 IPC 对象。

1
2
3
4
$ ipcs -q  # 查看创建的消息队列对象
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
0x00016978 32768      root       777        0            0

发送消息

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <stdio.h>
#include <stdlib.h>
#include <sys/msg.h>
#include <getopt.h>
#include <string.h>

struct msg_buffer {
    long mtype;
    char mtext[1024];
};

int main(int argc, char *argv[]) {
  int next_option;
  const char* const short_options = "i:t:m:";
  const struct option long_options[] = {
    { "id", 1, NULL, 'i'},
    { "type", 1, NULL, 't'},
    { "message", 1, NULL, 'm'},
    { NULL, 0, NULL, 0 }
  };
  
  int messagequeueid = -1;
  struct msg_buffer buffer;
  buffer.mtype = -1;
  int len = -1;
  char * message = NULL;
  do {
    next_option = getopt_long (argc, argv, short_options, long_options, NULL);
    switch (next_option)
    {
      case 'i':
        messagequeueid = atoi(optarg);
        break;
      case 't':
        buffer.mtype = atol(optarg);
        break;
      case 'm':
        message = optarg;
        len = strlen(message) + 1;
        if (len > 1024) {
          perror("message too long.");
          exit(1);
        }
        memcpy(buffer.mtext, message, len);
        break;
      default:
        break;
    }
  }while(next_option != -1);

  if(messagequeueid != -1 && buffer.mtype != -1 && len != -1 && message != NULL){
    if(msgsnd(messagequeueid, &buffer, len, IPC_NOWAIT) == -1){
      perror("fail to send message.");
      exit(1);
    }
  } else {
    perror("arguments error");
  }
  return 0;
}

发送消息主要调用 msgsnd 函数。第一个参数是 message queue 的 id，第二个参数是消息的结构体，第三个参数是消息的长度，最后一个参数是 flag。这里 IPC_NOWAIT 表示发送的时候不阻塞，直接返回。 getopt_long、do-while 循环以及 switch，是用来解析命令行参数的。命令行参数的格式定义在 long_options 里面。每一项的第一个成员“id”“type”“message”是参数选项的全称，第二个成员都为 1，表示参数选项后面要跟参数，最后一个成员’i’‘t’'m’是参数选项的简称。

编译并运行这个发送程序

1
2
gcc -o send sendmessage.c
./send -i 32768 -t 123 -m "hello world"

接收消息

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#include <stdio.h>
#include <stdlib.h>
#include <sys/msg.h>
#include <getopt.h>
#include <string.h>

struct msg_buffer {
    long mtype;
    char mtext[1024];
};

int main(int argc, char *argv[]) {
  int next_option;
  const char* const short_options = "i:t:";
  const struct option long_options[] = {
    { "id", 1, NULL, 'i'},
    { "type", 1, NULL, 't'},
    { NULL, 0, NULL, 0 }
  };
  
  int messagequeueid = -1;
  struct msg_buffer buffer;
  long type = -1;
  do {
    next_option = getopt_long (argc, argv, short_options, long_options, NULL);
    switch (next_option)
    {
      case 'i':
        messagequeueid = atoi(optarg);
        break;
      case 't':
        type = atol(optarg);
        break;
      default:
        break;
    }
  }while(next_option != -1);

  if(messagequeueid != -1 && type != -1){
    if(msgrcv(messagequeueid, &buffer, 1024, type, IPC_NOWAIT) == -1){
      perror("fail to recv message.");
      exit(1);
    }
    printf("received message type : %d, text: %s.", buffer.mtype, buffer.mtext);
  } else {
    perror("arguments error");
  }
  return 0;
}

收消息主要调用 msgrcv 函数，第一个参数是 message queue 的 id，第二个参数是消息的结构体，第三个参数是可接受的最大长度，第四个参数是消息类型, 最后一个参数是 flag，这里 IPC_NOWAIT 表示接收的时候不阻塞，直接返回。编译并运行这个发送程序。可以看到，如果有消息，可以正确地读到消息；如果没有，则返回没有消息。

1
2
3
4
$ ./recv -i 32768 -t 123
received message type : 123, text: hello world.
$ ./recv -i 32768 -t 123
fail to recv message.: No message of desired type

共享内存也是 System V IPC 进程间通信机制体系中的。

创建共享内存

创建一个共享内存，调用 shmget。在这个体系中，创建一个 IPC 对象都是 xxxget，第一个参数是 key，和 msgget 里面的 key 一样，都是唯一定位一个共享内存对象，也可以通过关联文件的方式实现唯一性。第二个参数是共享内存的大小。第三个参数如果是 IPC_CREAT，同样表示创建一个新的。

1
int shmget(key_t key, size_t size, int flag);

创建完毕之后，可以通过 ipcs 命令查看这个共享内存。

1
2
3
4
$ ipcs ­­--shmems
------ Shared Memory Segments ------ ­­­­­­­­
key        shmid    owner perms    bytes nattch status
0x00000000 19398656 marc  600    1048576 2      dest

访问共享内存

一个进程想要访问这一段共享内存，需要将内存加载到虚拟地址空间的某个位置，通过 shmat 函数，就是 attach 的意思。其中 addr 就是要指定 attach 到这个地方。这个地址的设定难度比较大，除非对于内存布局非常熟悉，否则可能会 attach 到一个非法地址。通常的做法是将 addr 设为 NULL，让内核选一个合适的地址。返回值就是真正被 attach 的地方。

1
void *shmat(int shm_id, const void *addr, int flag);

删除共享内存

共享内存使用完毕，可以通过 shmdt 解除绑定，然后通过 shmctl，将 cmd 设置为 IPC_RMID，从而删除这个共享内存对象。

1
2
int shmdt(void *addr); 
int shmctl(int shm_id, int cmd, struct shmid_ds *buf);

共享内存的创建和映射小结

1、调用 shmget 创建共享内存。

2、先通过 ipc_findkey 在基数树中查找 key 对应的共享内存对象 shmid_kernel 是否已经被创建过，如果已经被创建，就会被查询出来，例如 producer 创建过，在 consumer 中就会查询出来。

3、如果共享内存没有被创建过，则调用 shm_ops 的 newseg 方法，创建一个共享内存对象 shmid_kernel。例如，在 producer 中就会新建。

4、在 shmem 文件系统里面创建一个文件，共享内存对象 shmid_kernel 指向这个文件，这个文件用 struct file 表示，我们姑且称它为 file1。

5、调用 shmat，将共享内存映射到虚拟地址空间。

6、shm_obtain_object_check 先从基数树里面找到 shmid_kernel 对象。

7、创建用于内存映射到文件的 file 和 shm_file_data，这里的 struct file 我们姑且称为 file2。

8、关联内存区域 vm_area_struct 和用于内存映射到文件的 file，也即 file2，调用 file2 的 mmap 函数。

9、file2 的 mmap 函数 shm_mmap，会调用 file1 的 mmap 函数 shmem_mmap，设置 shm_file_data 和 vm_area_struct 的 vm_ops。

10、内存映射完毕之后，其实并没有真的分配物理内存，当访问内存的时候，会触发缺页异常 do_page_fault。

11、vm_area_struct 的 vm_ops 的 shm_fault 会调用 shm_file_data 的 vm_ops 的 shmem_fault。

12、在 page cache 中找一个空闲页，或者创建一个空闲页。

信号量(semaphore)

如果两个进程 attach 同一个共享内存，很有可能冲突。

需要一种保护机制，使得同一个共享的资源，同时只能被一个进程访问。在 System V IPC 进程间通信机制体系中，早就想好了应对办法，就是信号量（Semaphore）。因此，信号量和共享内存往往要配合使用（常用模式）。

信号量其实是一个计数器，主要用于实现进程间的互斥与同步，而不是用于存储进程间通信数据。

将信号量初始化为一个数值，来代表某种资源的总体数量。对于信号量来讲，会定义两种原子操作，一个是P 操作，我们称为申请资源操作。这个操作会申请将信号量的数值减去 N，表示这些数量被他申请使用了，其他人不能用了。另一个是V 操作，我们称为归还资源操作，这个操作会申请将信号量加上 M，表示这些数量已经还给信号量了，其他人可以使用了。

创建信号量

创建信号量可以通过 semget 函数（都是 xxxget）。第一个参数 key 也是类似的，第二个参数 num_sems 不是指资源的数量，而是表示可以创建多少个信号量，形成一组信号量，也就是说，如果你有多种资源需要管理，可以创建一个信号量组。

1
int semget(key_t key, int num_sems, int sem_flags);

接下来初始化信号量的总的资源数量。通过 semctl 函数，第一个参数 semid 是这个信号量组的 id，第二个参数 semnum 才是在这个信号量组中某个信号量的 id，第三个参数是命令，如果是初始化，则用 SETVAL，第四个参数是一个 union。如果初始化，应该用里面的 val 设置资源总量。

1
2
3
4
5
6
7
8
int semctl(int semid, int semnum, int cmd, union semun args);
union semun
{
  int val;
  struct semid_ds *buf;
  unsigned short int *array;
  struct seminfo *__buf;
};

pv操作

无论是 P 操作还是 V 操作，统一用 semop 函数。第一个参数还是信号量组的 id，一次可以操作多个信号量。第三个参数 numops 就是有多少个操作，第二个参数将这些操作放在一个数组中。

数组的每一项是一个 struct sembuf，里面的第一个成员是这个操作的对象是哪个信号量。

第二个成员就是要对这个信号量做多少改变。如果 sem_op < 0，就请求 sem_op 的绝对值的资源。如果相应的资源数可以满足请求，则将该信号量的值减去 sem_op 的绝对值，函数成功返回。

当相应的资源数不能满足请求时，就要看 sem_flg 了。如果把 sem_flg 设置为 IPC_NOWAIT，也就是没有资源也不等待，则 semop 函数出错返回 EAGAIN。如果 sem_flg 没有指定 IPC_NOWAIT，则进程挂起，直到当相应的资源数可以满足请求。若 sem_op > 0，表示进程归还相应的资源数，将 sem_op 的值加到信号量的值上。如果有进程正在休眠等待此信号量，则唤醒它们。

1
2
3
4
5
6
7
int semop(int semid, struct sembuf semoparray[], size_t numops);
struct sembuf 
{
  short sem_num; // 信号量组中对应的序号，0～sem_nums-1
  short sem_op;  // 信号量值在一次操作中的改变量
  short sem_flg; // IPC_NOWAIT, SEM_UNDO
}

信号量和共享内存都比较复杂，两者还要结合起来用，就更加复杂，它们内核的机制就更加复杂。

信号量的机制小结

1、调用 semget 创建信号量集合。

2、ipc_findkey 会在基数树中，根据 key 查找信号量集合 sem_array 对象。如果已经被创建，就会被查询出来。例如 producer 被创建过，在 consumer 中就会查询出来。

3、如果信号量集合没有被创建过，则调用 sem_ops 的 newary 方法，创建一个信号量集合对象 sem_array。例如，在 producer 中就会新建。

4、调用 semctl(SETALL) 初始化信号量。

5、sem_obtain_object_check 先从基数树里面找到 sem_array 对象。

6、根据用户指定的信号量数组，初始化信号量集合，也即初始化 sem_array 对象的 struct sem sems[]成员。

7、调用 semop 操作信号量。

8、创建信号量操作结构 sem_queue，放入队列。

9、创建 undo 结构，放入链表。

共享内存和信号量

共享内存和信号量的配合机制

无论是共享内存还是信号量，创建与初始化都遵循同样流程，通过 ftok 得到 key，通过 xxxget 创建对象并生成 id；
生产者和消费者都通过 shmat 将共享内存映射到各自的内存空间，在不同的进程里面映射的位置不同；
为了访问共享内存，需要信号量进行保护，信号量需要通过 semctl 初始化为某个值；
接下来生产者和消费者要通过 semop(-1) 来竞争信号量，如果生产者抢到信号量则写入，然后通过 semop(+1) 释放信号量，如果消费者抢到信号量则读出，然后通过 semop(+1) 释放信号量；
共享内存使用完毕，可以通过 shmdt 来解除映射。

信号(Signal)

上面讲的进程间通信的方式，都是常规状态下的工作模式，对应到咱们平时的工作交接，收发邮件、联合开发等，其实还有一种异常情况下的工作模式。

例如出现线上系统故障，这个时候，什么流程都来不及了，不可能发邮件，也来不及开会，所有的架构师、开发、运维都要被通知紧急出动。所以，7 乘 24 小时不间断执行的系统都需要有告警系统，一旦出事情，就要通知到人，哪怕是半夜，也要电话叫起来，处理故障。

对应到操作系统中，就是信号。信号没有特别复杂的数据结构，就是用一个代号一样的数字。Linux 提供了几十种信号，分别代表不同的意义。信号之间依靠它们的值来区分。这就像咱们看警匪片，对于紧急的行动，都是说，“1 号作战任务”开始执行，警察就开始行动了。情况紧急，不能啰里啰嗦了。

信号可以在任何时候发送给某一进程，进程需要为这个信号配置信号处理函数。当某个信号发生的时候，就默认执行这个函数就可以了。这就相当于咱们运维一个系统应急手册，当遇到什么情况，做什么事情，都事先准备好，出了事情照着做就可以了。

所有信号

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
$ kill -l # 查看所有信号
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

可以通过 man 7 signal 命令查看,

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process
SIGINT        2       Term    Interrupt from keyboard
SIGQUIT       3       Core    Quit from keyboard
SIGILL        4       Core    Illegal Instruction



SIGABRT       6       Core    Abort signal from abort(3)
SIGFPE        8       Core    Floating point exception
SIGKILL       9       Term    Kill signal
SIGSEGV      11       Core    Invalid memory reference
SIGPIPE      13       Term    Broken pipe: write to pipe with no
                              readers
SIGALRM      14       Term    Timer signal from alarm(2)
SIGTERM      15       Term    Termination signal
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2
……

每个信号都有唯一的 ID，还有遇到信号的默认操作（Action）。

信号处理方式

一旦有信号产生，用户进程对信号的处理方式：

1、执行默认操作。即上面列表中的 Action。如 Term 是终止进程的意思。 Core 是 Core Dump，终止进程后，通过Core Dump 将当前进程的运行状态保存在文件里面，方便事后分析。

2、捕捉信号。我们可以为信号定义一个信号处理函数。当信号发生时，我们就执行相应的信号处理函数。

3、忽略信号。但有两个信号是应用进程无法捕捉和忽略的，即 SIGKILL 和 SEGSTOP，它们用于在任何时候中断或结束某一进程。

信号处理流程

信号处理最常见的流程。这个过程主要是分成两步，第一步是注册信号处理函数。第二步是发送信号。

信号注册

signal

如果不想让某个信号执行默认操作，一种方法就是对特定的信号注册相应的信号处理函数，设置号处理方式的是 signal 函数。

1
2
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);

其实就是定义一个方法，并且将这个方法和某个信号关联起来。当这个进程遇到这个信号的时候，就执行这个方法。 signal 的 glibc 实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#  define signal __sysv_signal
__sighandler_t
__sysv_signal (int sig, __sighandler_t handler)
{
  struct sigaction act, oact;
......
  act.sa_handler = handler;
  __sigemptyset (&act.sa_mask);
  act.sa_flags = SA_ONESHOT | SA_NOMASK | SA_INTERRUPT;
  act.sa_flags &= ~SA_RESTART;
  if (__sigaction (sig, &act, &oact) < 0)
    return SIG_ERR;
  return oact.sa_handler;
}
weak_alias (__sysv_signal, sysv_signal)

sa_flags 进行了默认的设置。SA_ONESHOT 意思就是设置的信号处理函数，仅仅起作用一次。用完了一次就设置回默认行为。另外一个设置 SA_NOMASK。通过 __sigemptyset，将 sa_mask 设置为空。表示在这个信号处理函数执行过程中，如果再有其他信号（哪怕相同的信号），这个信号处理函数会被中断。

例如，如果是相同的信号，很可能操作的是同一个实例，同步、死锁等问题。一般的思路：某个信号的信号处理函数运行的时候，暂时屏蔽这个信号。屏蔽并不意味着信号一定丢失，而是暂存，这样能够做到信号处理函数对于相同的信号，处理完一个再处理下一个，信号处理函数的逻辑要简单很多。

还有一个设置就是设置了 SA_INTERRUPT，清除了 SA_RESTART。信号的到来时间是不可预期的，有可能程序正在调用某个漫长的系统调用的时候（可以在一台 Linux 机器上运行 man 7 signal 命令，在这里找 Interruption of system calls and library functions by signal handlers 的部分，里面说得非常详细），这个时候一个信号来了，会中断这个系统调用，去执行信号处理函数，那执行完后系统调用怎么处理？

有两种处理方法：一种是 SA_INTERRUPT，即系统调用被中断了，不再重试这个系统调用了，而是直接返回一个 -EINTR 常量，告诉调用方系统调用被信号中断了，但是怎么处理你看着办。这样调用方可以根据自己的逻辑，重新调用或直接返回，这会使得代码非常复杂，在所有系统调用的返回值判断里面，都要特殊判断一下这个值。

另外一种处理方法是 SA_RESTART。这个时候系统调用会被自动重新启动，不需要调用方自己写代码。（当然也可能存在问题，例如从终端读入一个字符'a'，处理'a'字符的时候被信号中断了，等信号处理完毕再次读入一个字符时，如果用户不再输入就阻塞，需要用户再次输入同一个字符。）

因此建议使用 sigaction 函数，根据需要定制参数。

sigaction

如果在 Linux 下面执行 man signal 的话，会发现 Linux 不建议直接用这个方法，而是改用 sigaction。定义如下：

1
2
int sigaction(int signum, const struct sigaction *act,
                     struct sigaction *oldact);

其实它还是将信号和一个动作进行关联，只不过这个动作由一个结构 struct sigaction 表示了。

1
2
3
4
5
6
struct sigaction {
  __sighandler_t sa_handler;
  unsigned long sa_flags;
  __sigrestore_t sa_restorer;
  sigset_t sa_mask;    /* mask last for extensibility */
};

和 signal 类似的是，这里面有 __sighandler_t。但是，其他成员变量可以更加细致地控制信号处理的行为。而 signal 函数没有机会设置这些。这里需要注意的是，signal 不是系统调用，而是 glibc 封装的一个函数。这样就像 man signal 里面写的一样，不同的实现方式，设置的参数会不同，会导致行为的不同。 glibc 里面有个文件 syscalls.list。定义了库函数调用哪些系统调用，这里包含 sigaction。

glibc 中，__sigaction 会调用 __libc_sigaction，并最终调用的系统调用是 rt_sigaction。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
int
__sigaction (int sig, const struct sigaction *act, struct sigaction *oact)
{
......
  return __libc_sigaction (sig, act, oact);
}

int
__libc_sigaction (int sig, const struct sigaction *act, struct sigaction *oact)
{
  int result;
  struct kernel_sigaction kact, koact;

  if (act)
    {
      kact.k_sa_handler = act->sa_handler;
      memcpy (&kact.sa_mask, &act->sa_mask, sizeof (sigset_t));
      kact.sa_flags = act->sa_flags | SA_RESTORER;

      kact.sa_restorer = &restore_rt;
    }

  result = INLINE_SYSCALL (rt_sigaction, 4,
                           sig, act ? &kact : NULL,
                           oact ? &koact : NULL, _NSIG / 8);
  if (oact && result >= 0)
    {
      oact->sa_handler = koact.k_sa_handler;
      memcpy (&oact->sa_mask, &koact.sa_mask, sizeof (sigset_t));
      oact->sa_flags = koact.sa_flags;
      oact->sa_restorer = koact.sa_restorer;
    }
  return result;
}

我们的库函数虽然调用的是 sigaction，到了系统调用层，调用的可不是系统调用 sigaction，而是系统调用 rt_sigaction。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
SYSCALL_DEFINE4(rt_sigaction, int, sig,
    const struct sigaction __user *, act,
    struct sigaction __user *, oact,
    size_t, sigsetsize)
{
  struct k_sigaction new_sa, old_sa;
  int ret = -EINVAL;
......
  if (act) {
    if (copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)))
      return -EFAULT;
  }

  ret = do_sigaction(sig, act ? &new_sa : NULL, oact ? &old_sa : NULL);

  if (!ret && oact) {
    if (copy_to_user(oact, &old_sa.sa, sizeof(old_sa.sa)))
      return -EFAULT;
  }
out:
  return ret;
}

在 rt_sigaction 里面将用户态的 struct sigaction 结构，拷贝为内核态的 k_sigaction，然后调用 do_sigaction。进程内核的数据结构里 struct task_struct 里面有一个成员 sighand，里面有一个 action。这是一个数组，下标是信号，内容就是信号处理函数，do_sigaction 就是设置 sighand 里的信号处理函数。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
int do_sigaction(int sig, struct k_sigaction *act, struct k_sigaction *oact)
{
  struct task_struct *p = current, *t;
  struct k_sigaction *k;
  sigset_t mask;
......
  k = &p->sighand->action[sig-1];

  spin_lock_irq(&p->sighand->siglock);
  if (oact)
    *oact = *k;

  if (act) {
    sigdelsetmask(&act->sa.sa_mask,
            sigmask(SIGKILL) | sigmask(SIGSTOP));
    *k = *act;
......
  }

  spin_unlock_irq(&p->sighand->siglock);
  return 0;
}

至此，信号处理函数的注册已经完成了。 信号注册小结

在用户程序里面，有两个函数可以调用，一个是 signal，一个是 sigaction，推荐使用 sigaction。
用户程序调用的是 Glibc 里面的函数，signal 调用的是 __sysv_signal，里面默认设置了一些参数，使得 signal 的功能受到了限制，sigaction 调用的是 __sigaction，参数用户可以任意设定。
无论是 __sysv_signal 还是 __sigaction，调用的都是统一的一个系统调用 rt_sigaction。
在内核中，rt_sigaction 调用的是 do_sigaction 设置信号处理函数。在每一个进程的 task_struct 里面，都有一个 sighand 指向 struct sighand_struct，里面是一个数组，下标是信号，里面的内容是信号处理函数。

信号发送处理

有时候，我们在终端输入某些组合键的时候，会给进程发送信号，例如，Ctrl+C 产生 SIGINT 信号，Ctrl+Z 产生 SIGTSTP 信号。

硬件异常也会产生信号。比如，执行了除以 0 的指令，CPU 就会产生异常，然后把 SIGFPE 信号发送给进程。再如，进程访问了非法内存，内存管理模块就会产生异常，然后把信号 SIGSEGV 发送给进程。

注意，同样是硬件产生的，中断和信号的区别：中断要注册中断处理函数，但是中断处理函数是在内核驱动里面的，信号也要注册信号处理函数，但是在用户态进程里面。

对于硬件触发的，无论是中断还是信号，肯定是先到内核的，然后内核对于中断和信号处理方式不同。一个是完全在内核里面处理完毕，一个是将信号放在对应的进程 task_struct 里信号相关的数据结构里面，然后等待进程在用户态去处理。当然有些严重的信号，内核会把进程干掉。中断和信号的严重程度不一样，信号影响的往往是某一个进程，处理慢了或最多也不过这个进程被干掉，而中断影响的是整个系统，一旦中断处理中有了 bug，可能整个 Linux 都挂了。

内核在某些情况下，也会给进程发送信号。例如，向读端已关闭的管道写数据时产生 SIGPIPE 信号，当子进程退出时，我们要给父进程发送 SIG_CHLD 信号等。

最直接的发送信号的方法就是，通过命令 kill 来发送信号了。例如，我们都知道的 kill -9 pid 可以发送信号给一个进程，杀死它。

另外，我们还可以通过 kill 或者 sigqueue 系统调用，发送信号给某个进程，也可以通过 tkill 或者 tgkill 发送信号给某个线程。虽然方式多种多样，但是最终都是调用了 do_send_sig_info 函数，将信号放在相应的 task_struct 的信号数据结构中。

各个命令调用链路如下：

kill->kill_something_info->kill_pid_info->group_send_sig_info->do_send_sig_info
tkill->do_tkill->do_send_specific->do_send_sig_info
tgkill->do_tkill->do_send_specific->do_send_sig_info
rt_sigqueueinfo->do_rt_sigqueueinfo->kill_proc_info->kill_pid_info->group_send_sig_info->do_send_sig_info

do_send_sig_info 会调用 send_signal，进而调用 __send_signal。

进程数据结构中 task_struct 里面的 sigpending。上面的代码先要决定应该用哪个 sigpending。取决于信号是给进程的还是线程的。如果是 kill 发送的，也就是发送给整个进程的，就应该发送给 t->signal->shared_pending。这里面是整个进程所有线程共享的信号。如果是 tkill 发送的，也就是发给某个线程的，应该发给 t->pending。这里面是这个线程的 task_struct 独享的。

struct sigpending 里面有两个成员，一个是集合 sigset_t，表示收到了哪些信号，另一个链表，也表示收到了哪些信号。结构如下：

1
2
3
4
struct sigpending {
  struct list_head list;
  sigset_t signal;
};

两者的区别（细节较多，暂略）

信号的发送与处理流程

1、假设有一个进程 A，main 函数里面调用系统调用进入内核。

2、按照系统调用的原理，会将用户态栈的信息保存在 pt_regs 里面，也即记住原来用户态是运行到了 line A 的地方。

3、在内核中执行系统调用读取数据。

4、当发现没有什么数据可读取的时候，进入睡眠状态，并且调用 schedule 让出 CPU，这是进程调度第一定律。

5、将进程状态设置为 TASK_INTERRUPTIBLE，可中断的睡眠状态，也即如果有信号来的话，是可以唤醒它的。

6、其他的进程或者 shell 发送一个信号，有四个函数可以调用 kill、tkill、tgkill、rt_sigqueueinfo。

7、四个发送信号的函数，在内核中最终都是调用 do_send_sig_info。

8、do_send_sig_info 调用 send_signal 给进程 A 发送一个信号，其实就是找到进程 A 的 task_struct，或者加入信号集合，为不可靠信号，或者加入信号链表，为可靠信号。

9、do_send_sig_info 调用 signal_wake_up 唤醒进程 A。

10、进程 A 重新进入运行状态 TASK_RUNNING，根据进程调度第一定律，一定会接着 schedule 运行。

11、进程 A 被唤醒后，检查是否有信号到来，如果没有，重新循环到一开始，尝试再次读取数据，如果还是没有数据，再次进入 TASK_INTERRUPTIBLE，即可中断的睡眠状态。

12、当发现有信号到来的时候，就返回当前正在执行的系统调用，并返回一个错误表示系统调用被中断了。

13、系统调用返回的时候，会调用 exit_to_usermode_loop。这是一个处理信号的时机。

14、调用 do_signal 开始处理信号。

15、根据信号，得到信号处理函数 sa_handler，然后修改 pt_regs 中的用户态栈的信息，让 pt_regs 指向 sa_handler。同时修改用户态的栈，插入一个栈帧 sa_restorer，里面保存了原来的指向 line A 的 pt_regs，并且设置让 sa_handler 运行完毕后，跳到 sa_restorer 运行。

16、返回用户态，由于 pt_regs 已经设置为 sa_handler，则返回用户态执行 sa_handler。

17、sa_handler 执行完毕后，信号处理函数就执行完了，接着根据第 15 步对于用户态栈帧的修改，会跳到 sa_restorer 运行。

18、sa_restorer 会调用系统调用 rt_sigreturn 再次进入内核。

19、在内核中，rt_sigreturn 恢复原来的 pt_regs，重新指向 line A。

20、从 rt_sigreturn 返回用户态，还是调用 exit_to_usermode_loop。

21、这次因为 pt_regs 已经指向 line A 了，于是就到了进程 A 中，接着系统调用之后运行，当然这个系统调用返回的是它被中断了，没有执行完的错误。

套接字(socket)

Reference

https://www.jianshu.com/p/c1015f5ffa74

2.5 - 文件系统

Introduction

文件系统相关

2.5.1 - Linux文件系统-01设备

Linux文件系统

简介

Linux有多种文件系统，不同的文件系统支持不同的体系。文件系统是管理数据的，而存储数据的物理设备有硬盘、 U盘、 SD卡、 NAND FLASH、 NOR FLASH、网络存储设备等。不同的存储设备有不同的物理结构，因此就需要不同的文件系统去管理，比如管理 NAND FLASH 使用YAFFS 文件系统，管理硬盘/SD卡使用ext文件系统等。

分类

Linux支持很多文件系统格式，常见文件系统类型：

ext2 ：早期linux中常用的文件系统

ext3 ： ext2的升级版，带日志功能

RAMFS ：内存文件系统，速度很快

NFS ：网络文件系统，由SUN发明，主要用于远程文件共享

MS-DOS ： MS-DOS文件系统

VFAT ： Windows 95/98 操作系统采用的文件系统

FAT ： Windows XP 操作系统采用的文件系统

NTFS： Windows NT/XP 操作系统采用的文件系统

HPFS ： OS/2 操作系统采用的文件系统

PROC : 虚拟的进程文件系统

ISO9660 ：大部分光盘所采用的文件系统

ufsSun : OS 所采用的文件系统

NCPFS ： Novell 服务器所采用的文件系统

SMBFS ： Samba 的共享文件系统

XFS ：由SGI开发的先进的日志文件系统，支持超大容量文件

JFS ：IBM的AIX使用的日志文件系统

ReiserFS : 基于平衡树结构的文件系统

udf: 可擦写的数据光盘文件系统

大体可分以下几类：

磁盘文件系统

指本地主机中实际可以访问到的文件系统，包括硬盘、CD-ROM、DVD、USB存储器、磁盘阵列等。常见格式有：Ext2、Ext3、Ext4、JFS、NTFS、UFS、FAT、FAT16、FAT32等

网络文件系统

是可以远程访问的文件系统，在服务器端仍是本地磁盘文件系统，客户机通过网络远程访问数据。常见格式有：NFS、Samba等

专有/虚拟文件系统

不驻留在磁盘上的文件系统。常见格式有：TMPFS、PROCFS等。

磁盘文件系统

目前Ext4（Extended File sytem，扩展文件系统）是广泛使用的一种磁盘文件系统格式。是在Ext3基础上发展起来的，对有效性保护、数据完整性、数据访问速度、向下兼容性等方面做了改进，其特点是日志文件系统：可将整个磁盘的写入动作完整地记录在磁盘的某个区域上，以便在必要时回溯追踪。

磁盘是一种计算机的外部存储器设备，由一个或多个覆盖有磁性材料的铝制或玻璃制的碟片组成，用来存储用户的信息，这种信息可以反复地被读取和改写。磁盘主要分为一下几类：

IDE磁盘

Integrated Drive Electronics，价格低廉，兼容性强，性价比高，但是数据传输慢，不支持热插拔等。

SCSI磁盘

Small Computer System Interface，传输速率高，读写性能好，运行稳定，可连接多个设备，支持热插拔，占用CPU低，但是价格相对较贵，一般用于工作站或服务器上。

SATA磁盘

Serial Advanced Technology Attachment，结构简单、支持热插拔。

磁盘分区

为了便于管理和使用，通常会对磁盘进行分区。

主分区

必须要存在的分区，最多能创建4个，最少1个，编号只能是1 - 4 （比如sda1、sda2、sda3、sda4），可以直接格式化，然后安装系统直接存放文件。

扩展分区

会占用主分区位置，即主分区+扩展分区之和最多4个。相当于独立的磁盘，有独立的分区表，但不能独立的存放数据

逻辑分区

扩展分区不能直接存放数据，必须经过再次分割成为逻辑分区后才能存放数据。一个扩展分区中的逻辑分区可以有任意多个，编号只能从5开始。

交换分区

安装系统时建立的，一块特殊的硬盘空间，当实际内存不够用时，操作系统会从内存中取出部分暂时不用的数据，放在swap中，为当前程序腾出足够的内存空间。swap不会使用到目录树的挂载，无需指定挂载点（即cd无法进入）。

设备

设备接入系统后都是以文件的形式存在

设备文件名称

设备类型	文件名称
SATA/SAS/USB	/dev/sda,/dev/sdb （s= SATA, d=DISK a=第几块）
IDE	/dev/hd0,/dev/hd1 （h= hard）
VIRTIO-BLOCK	/dev/vda,/dev/vdb （v=virtio）虚拟io输出
M2（SSD）	/dev/nvme0,/dev/nvme1（nvme=m2）
SD/MMC/EMMC(卡)	/dev/mmcblk0,/dev/mmcblk1（mmcblk=mmc卡）
光驱	/cdrom,/dev/sr0,/dev/sr1

设备命令规则

1
2
3
4
5
6
7
/dev/sd  a  5
-1   -2 -3 -4
分别以数字代替上述位置
-1：硬件设备所在目录
-2：设备，sd表示SCSI设备，hd表示IDE设备
-3：磁盘的顺序号以字母a、b、c...表示
-4：分区的顺序号，以1、2、3...表示

举例：

1
2
3
4
/dev/sda  # 表示第一个SCSI硬盘
/dev/sda1 # 表示第一个SCSI硬盘的第一个主分区
/dev/sdb3 # 表示第二个SCSI硬盘的第3个主分区
/dev/hdb  # 表示第二个IDE硬盘的第2个主分区

文件系统结构

除了swap分区外，其他主分区、扩展分区、逻辑分区都是在根分区（/）目录上操作的。Linux文件系统是一个树形的分层组织结构，根作为整个文件系统的唯一起点，其他所有目录都从该点出发。根分区下的一级目录有：

bin
boot
dev
etc
home
lib
mnt
opt
proc
root
sbin
srv
sys
tmp
usr
var

操作命令

fdisk

磁盘分区表操作工具。命令格式：

1
fdisk [-l]

常用选项：

1
-l: 输出后面接的装置所有的分区内容。

file

file命令用于辨识文件类型。命令的格式为：

1
file [-b -c -L -v -z][-f <名称文件>][-m <魔法数字文件>...][文件或目录...]

常用选项：

1
2
3
4
5
6
7
8
-b: 列出辨识结果时不显示文件名称
-c: 详细列出指令执行过程
-f <名称文件>: 执行名称文件
-L: 直接显示符号链接所指向的文件的类别
-m <魔法数字文件>: 执行魔法数字文件
-v: 显示版本信息
-z: 尝试解读压缩文件内容
[文件或目录...]: 要确定类型的文件列表，多个文件之间以空格隔开，也可以使用shell通配符匹配

ln

link files的缩写，是为某一个文件在另外一个位置建立一个同步的链接。

命令格式：

1
ln [参数][源文件或目录][目标文件或目录]

常用选项：

1
2
3
4
5
6
7
-b: 删除、覆盖之前建立的链接
-d: 允许超级用户制作目录的硬链接
-f: 强制执行
-i: 交互模式，文件存在则提示是否覆盖
-n: 把符号连接视为一般目录
-s: 软链接(符号链接)
-v: 显示详细处理过程

mount

挂载本地设备

对分区/dev/sda3的操作命令：

1、挂载：mount /dev/sda1 /mnt/asd，这样挂载分区到文件系统上，才能看/mnt/asd里的东西。

2、查看：ls -hl /mnt/asd

3、卸载：umount /dev/sda1

文件系统：指定要卸载的文件系统或者其对应的设备文件名

(1)、通过设备名卸载：umount -v /dev/sda1

(2)、通过挂载点卸载：umount -v /mnt/mymount/

挂载网络设备

挂载 NFS 服务作为网络磁盘：

1
2
sudo mount -t nfs <NFS_server_IP>:<NFS_share_path> <mount_point>
# sudo mount -t nfs 192.168.1.100:/nfs/share /mnt/nfs

挂载后，可以在 /mnt/nfs 目录下查看 NFS 服务器上的文件。要在系统启动时自动挂载 NFS，可以将以上命令添加到 /etc/fstab 文件中，例如：

1
192.168.1.100:/nfs/share /mnt/nfs nfs defaults 0 0

注意：在生产环境中，使用前需要调整访问安全性的设置，并确保挂载的代码的正确性。

设备查看

命令	作用
fdisk -l	查看磁盘分区情况
lsblk	设备使用情况
blkid	设备管理方式及设备ID
df	查看正在被系统挂载的设备
cat /proc/partitions	查看系统识别设备

Reference

https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/device_naming.html

Linux存储设备管理

https://blog.51cto.com/u_15467009/5575719

3 - NetWork

Introduction

计算机网络

3.1 - 端口转发socat

简介

socat 功能跟 NetCat 一样，但更安全(支持 chroot )，兼容多种协议，支持操作文件 ( file )、管道 ( pipe )、设备 ( device )、 TCP 套接字、 Unix 套接字、 SOCKS 客户端、 CONNECT 代理以及 SSL 等等。

安装

1
sudo apt update && sudo apt install socat

端口转发

1
2
3
4
5
6
7
8
# 将 80 端口转发到 202.54.1.5 
socat TCP-LISTEN:80,fork TCP:202.54.1.5:80

# 转发TCP
nohup socat TCP4-LISTEN:30000,reuseaddr,fork TCP4:1.1.1.1:30000 >> socat.log 2>&1 &

# 转发UDP
nohup socat -T 600 UDP4-LISTEN:10000,reuseaddr,fork UDP4:1.1.1.1:10000 >> socat.log 2>&1 &

1
2
3
4
# 通过 socat 转发 2280 端口，以支持某些不支持 CONSUL_HTTP_HOST 的库的运行
if type "socat" > /dev/null 2>&1; then
  nohup socat TCP-LISTEN:2280,range=127.0.0.1/32,reuseaddr,fork TCP:$CONSUL_HTTP_HOST:2280 > /dev/null 2>&1 &
fi

实际使用

1
ssh -f -N -L 2280:127.0.0.1:2280 zhangsan@1.23.2.5

运行：bash socat_hb.sh 10.231.243.5

1
2
3
4
#!/bin/bash
echo "READY TO CONNECT TO: $1"
socat -d -d TCP4-LISTEN:2280,fork TCP4:$1:2280 &
socat -d -d TCP4-LISTEN:2150,fork TCP4:$1:2150

ssh端口转发

ssh基本操作

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 生成公私钥

# 将所有的ssh公钥发送到服务器
ssh-copy-id zhangsan@ip
man ssh-copy-id
cat .ssh/id_rsa.pub | ssh zhangsan@ip tee .ssh/authorized_keys

# scp拷贝小文件
touch 1.tmp
scp 1.tmp zhangsan@ip:/tmp/foobar.md

# rsync 拷贝大文件
rsync -avP ./clean-pvnet zhangsan@ip:clean

ssh zhangsan@ip touch .ssh/authorized_keys
# 修改ssh配置文件
vi /etc/ssh/ssd_config
# 具体内容自行搜索，可修改登陆方式/端口等
# ssh重新加载
service sshd reload

# 使用其它端口登陆ssh
ssh zhangsan@ip -p7222
curl localhost:7222

ssh正向转发

将当前的请求转发到远程服务器

1
2
# 公式，123为本机端口，456为远程端口
ssh -L 123:loclhost:456 remotehost

ssh反向转发

将远程服务器的请求转发到本机

1
2
# 公式，123为本机端口，456为远程端口
ssh -R 123:localhost:456 remotehost

3.2 - 认证鉴权

Introduction

认证鉴权

3.2.1 - OAuth2介绍

四种方式

授权码

**授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。**授权码只能使用一次

获取UserToken时序图

举例百度获取微信认证

步骤：

1、A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。

2、用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码。

3、A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

4、B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

隐藏式

1、A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

2、用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了

密码式

高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）

凭证式

凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

Reference

微信开放平台

OAuth2.0的四种方式

GitHub OAuth 第三方登录示例教程

3.3 - protocol

Introduction

协议

3.3.1 - HTTP协议介绍

HTTP/1.0

无状态无连接的应用层协议

无状态：服务不跟踪不记录请求过的状态
无连接：浏览器每次请求都需要建立 TCP 连接 HTTP/1.0 规定浏览器和服务器保持短暂的连接。浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开 TCP 连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。无状态导致的问题可以借助 cookie/session 机制来做身份认证和状态记录解决。

然而，无连接特性将会导致以下性能缺陷：

无法复用连接。每次发送请求都需要进行一次 TCP 连接，而 TCP 连接和释放都比较麻烦，会导致网络的利用率非常低。
队头堵塞(head of line blocking)。由于 HTTP/1.0 规定下一个请求必须在前一个请求响应到达之前才能发送。假设一个请求响应一直不到达，那么下一个请求就不发送，就到导致阻塞后面的请求。为了解决这些问题，HTTP/1.1出现了。

HTTP/1.1

HTTP/1.1 的改进：

长连接

增加了一个 Connection 字段，设置为 keep-alive（默认值）可以保持连接不断开，避免每次请求都要重新建立 TCP 连接。客户端关闭连接可通过设置 Connection: fase 来告诉服务器关闭请求。

请求管道化

支持请求管道化，即 pipelining

基于 HTTP/1.1 的长连接，使得请求管线化成为可能。管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多图片，这时 keep-alive 能够进行“并行”发送多个请求。

注意：这里的“并行”并不是真正的并行。服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

可见，HTTP/1.1还是无法解决队头阻塞（head of line blocking）的问题。同时“管道化”技术存在各种各样的问题，所以很多浏览器要么根本不支持它，要么就直接默认关闭，并且开启的条件很苛刻，实际上好像并没有什么用处。

补充：在 Chrome 等浏览器控制台看到的并行请求是通过允许打开多个 TCP 会话来实现的真正的并行。

缓存处理

断点传输

cache-control 字段

Host

一个服务器能够利用 Host 字段用来创建多个Web站点

SPDY

背景

虽然 HTTP1.0 和 HTTP 1.1 存在这么多问题，业界也是想出了各种优化手段，但都是治标不治本，直到 SPDY 的诞生。

SPDY 是由 Google 在2020年提出的方案，改进版本的HTTP1.1 （那时候还没有HTTP2）。它基于TCP协议，在HTTP的基础上，结合HTTP1.X的多个痛点进行改进和升级的产物。它的出现让大家开始从正面看待和解决老版本 HTTP 协议本身的问题，使web的加载速度有极大的提高。HTTP2也借鉴了很多 SPDY 的特性。

目标

SPDY 的目标在于解决 HTTP 的缺陷，即延迟和安全性。我们上面一直在讨论延迟，至于安全性，虽然我们上面没有具体聊，不过 HTTP 的明文传输确是个问题。如果以降低延迟为目标，应用层的 HTTP 和传输层的 TCP 都是都有调整的空间，不过 TCP 作为更底层协议存在已达数十年之久，其实现已深植全球的网络基础设施当中，如果要动必然伤经动骨，业界响应度必然不高，所以 SPDY 的手术刀对准的是 HTTP 。

降低延迟，客户端的单连接单请求，服务端的 FIFO 响应队列都是延迟的大头。
HTTP 最初设计都是客户端发起请求，然后服务端进行响应，服务端无法主动发送内容到客户端。
压缩 HTTP header，HTTP 1.x 的 header 越来越膨胀，cookie 和 user agent 很容易让 header 的 size 增至1kb 大小甚至更多。而且由于 HTTP 的无状态特性，header 必须每次请求都重复携带，很浪费流量。为了增加解决这些问题的可行性，Google 一开始就避开了从传输层动手，而且打算利用开源社区的力量以提高扩散的力度，对于协议使用者来说，也只需要在请求的 header 里设置 user agent，然后在服务端做好支持即可，极大的降低了部署的难度。SPDY 的设计如下：

SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将http1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。SPDY的功能可以分为基础功能和高级功能两部分，基础功能默认启用，高级功能需要手动启用。

基础功能

多路复用(multiplexing) 多路复用通过多个请求共用一个连接的方式，降低了 TCP 连接建立和释放的开销，同时提高了带宽的利用率。
请求优先级(request prioritization) 多路复用带来的一个问题是，在共享连接的基础上会存在一些关键请求被阻塞，SPDY 允许给每个请求设置优先级，这样重要的请求就会优先得到响应。
header 压缩前面提到的 HTTP 1.x 的 header 很多时候都是重复而且多余的。选择合适的压缩算法可以减小包的大小和数量。SPDY 对 header 的压缩素可以达到 80% 以上。

高级功能

服务端推送 HTTP 只能由客户端发送，服务器只能被动发送响应。不过在开启服务端推送后，服务端通过 **X-Associated-Content ** header 会告知服务器会有新的内容被推送过来，
服务端暗示和服务端推送所不同的是，服务端暗示不会推送内容，只是告诉客户端有新的内容产生，，内容的下载还是需要客户端主动发起请求。服务端暗示通过 X-Subresources header 来通知，一般应用场景是客户端需要先查询服务端状态，然后再下载资源，可以节约一次查询请求。

自从 SPDY 出现后，页面加载时间相比于 HTTP 减少了 64%，而且各大浏览器厂商在 SPDY 诞生之后的 1 年多时间里也都陆续支持了 SPDY。但是，SPDY 的生存时间却没有人们想象中的那么长，SPDY 从 2012 年诞生到 2016 年停止维护。

HTTP/2.0

基本概念

帧

HTTP/2.0 数据通信的最小单位消息：指 HTTP/2.0 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。

流

连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID。

消息

与逻辑消息对应的完整的一系列数据帧。

兼容HTTP/1.1

二进制分帧

http1.x诞生的时候是明文协议，其格式由三部分组成：start line（request line或者status line），header，body。要识别这3部分就要做协议解析，http1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑http2.0的协议解析决定采用二进制格式，实现方便且健壮。

HTTP/2.0 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式，二进制协议解析起来更高效。 HTTP/1.x 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2.0 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

http2.0用binary格式定义了一个一个的frame，和http1.x的格式对比如下图：

http2.0的格式定义更接近tcp层的方式，这张二机制的方式十分高效且精简。length定义了整个frame的开始到结束，type定义frame的类型（一共10种），flags用bit位定义一些重要的参数，stream id用作流控制，剩下的payload就是request的正文了。

虽然看上去协议的格式和http1.x完全不同了，实际上http2.0并没有改变http1.x的语义，只是把原来http1.x的header和body部分用frame重新封装了一层而已。调试的时候浏览器甚至会把http2.0的frame自动还原成http1.x的格式。具体的协议关系可以用下图表示：

多路复用

同域名下的所有通信都在单个连接中完成。
单个连接可以承载任意数量的双向数据流。
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。性能有很大提升。
同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
单个连接上可以并行交错地请求和响应，之间互不干扰。
每个请求都可以带一个31bit的优先值（0表示最高优先级，数值越大优先级越低）。客户端和服务器可以在处理不同流时采取不同策略，以最优的方式发送流、消息和帧。在 HTTP/1.1 协议中，浏览器客户端在同一时间、针对同一域名下的请求有一定数量限制，超过限制数据的请求会被阻塞。

而 HTTP/2.0 实现了真正的并行传输，能够在一个 TCP 上进行任意数量 HTTP 请求。而这个强大的功能则是基于“二进制分帧”的特性。

多路复用对延迟的改变可以参考：https://http2.akamai.com/demo

服务器推送

服务端可以主动推送，在发送页面 HTML 时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。

客户端也有权选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送 RST_STREAM 帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。

头部压缩

在 HTTP/1.x 中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加 500~800 字节的负荷。

HTTP/2.0 使用 encoder 来减少需要传输的 header 大小，通讯双方各自 cache 一份 header fields 表，既避免了重复 header 的传输，又减小了需要传输的大小。高效的压缩算法可以很大地压缩 header，减少发送包的数量从而降低延迟。

QUIC

简介

QUIC 是一种建立在 UDP 之上的新型多路复用传输。HTTP/3 旨在利用 QUIC 的功能，包括缺少流之间的 Head-Of-Line 阻塞。

特性

基于UDP建立的连接

基于TCP的协议，如http2，在首次建立连接的时候需要进行三次握手，即至少需要3个ntt，而考虑安全HTTPS的TLS层，又需要至少次的通信才能协商出密钥。这在短连接的场景中极大的增加了网络延迟，而这种延迟是无法避免的。

而基于UDP的quic协议，则不需要3次握手的过程，甚至在安全协商阶段只需要进行1~2次的协商通信，即可建立安全稳定的连接，极大的减少了网络延迟。

基于Diffie-Hellman的加密算法

HTTPS 使用的是 TLS + SSL 的加密手段，在交换证书、协商密钥的过程中，至少需要2次ntt进行协商通信。而quic使用了Diffie-Hellman算法，算法的原理使得客户端和浏览器之间只需要1次的协商就能获得通信密钥，quic建立安全链接的详细过程：

客户端发起Inchoate client hello
服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端
客户端发起client hello，包括客户端公钥信息后续发起连接的过程中，一旦客户端缓存或持久化了server config，就可以复用并结合本地生成的私钥进行加密数据传输了，不需要再次握手，从而实现0RTT建立连接。

连接的迁移

在以往的基于TCP的协议中，往往使用四元组（源IP，源端口，目的IP，目的端口）来标识一条连接，当四元组中的IP或端口任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。

而QUIC使用了connection id对连接进行唯一标识。即使网络从4G变成了wifi，只要两次连接中的 connection id不变，并且客户端或者服务器能通过校验，就不需要重新建立连接，连接迁移就能成功。

这在移动端场景的优势极为明显，因为手机经常会在wifi和4g中切换，使用quic协议降低了重建连接的成本。

协商的升级

在chorme浏览器中，发起一个TCP请求，这个请求会同时与服务器开始建立tcp 和 quic 的连接（前提是服务器支持），如果quic连接先建立成功，则使用quic建立的连接通信，反之，则使用tcp建立的连接进行通信。具体步骤如下：

客户端发出tcp请求
服务端如果支持quic可以通过响应头alt-svc告知客户端
客户端同时发起tcp连接和quic连接竞赛
一旦quic建立连接获胜则采用quic协议发送请求
如遇网络或服务器不支持quic/udp，客户端标记quic为broken
传输中的请求通过tcp重发
5min后尝试重试quic，下一次尝试增大到10min
一旦再次成功采用quic并把broken标记取消

其他特性

改进的拥塞控制
丢包恢复
底层的连接持久化
head stream 保证包顺序
双级别流量控制

HTTP3

背景

HTTP2协议虽然大幅提升了HTTP/1.1的性能，然而，基于TCP实现的HTTP2遗留下3个问题：

有序字节流引出的队头阻塞（Head-of-line blocking），使得HTTP2的多路复用能力大打折扣；TCP与TLS叠加了握手时延，建链时长还有1倍的下降空间；基于TCP四元组确定一个连接，这种诞生于有线网络的设计，并不适合移动状态下的无线网络，这意味着IP地址的频繁变动会导致TCP连接、TLS会话反复握手，成本高昂。

解决的问题

HTTP3基于UDP协议重新定义了连接，在QUIC层实现了无序、并发字节流的传输，解决了队头阻塞问题（包括基于QPACK解决了动态表的队头阻塞）；HTTP3重新定义了TLS协议加密QUIC头部的方式，既提高了网络攻击成本，又降低了建立连接的速度（仅需1个RTT就可以同时完成建链与密钥协商）；HTTP3 将Packet、QUIC Frame、HTTP3 Frame分离，实现了连接迁移功能，降低了5G环境下高速移动设备的连接维护成本。

基于TCP协议的好处是可以把网络数据的完整性由传输层保证，应用层只用关心传输什么内容，如何利用这些内容实现应用功能。 HTTP/3是基于UDP协议的，传输数据的完全性由应用层来保证。

各协议区别

keep-alive与多路复用区别

HTTP/1.x 是基于文本的，只能整体去传；HTTP/2 是基于二进制流的，可以分解为独立的帧，交错发送
HTTP/1.x keep-alive 必须按照请求发送顺序返回响应；HTTP/2 多路复用不按序响应
HTTP/1.x keep-alive 为了解决队头阻塞，将同一个页面的资源分散到不同域名下，开启了多个 TCP 连接；HTTP/2 同域名下所有通信都在单个连接上完成
HTTP/1.x keep-alive 单个 TCP 连接在同一时刻只能处理一个请求（两个请求的生命周期不能重叠）；HTTP/2 单个 TCP 同一时刻可以发送多个请求和响应

pipelining与多路复用

HTTP/1.1 版本的管线化（pipelining）理论，默认关闭。与 HTTP/2.0 的多路复用比较类似，具体是什么区别？

HTTP/1.1 的管线化只能串行，即一个相应必须完全返回后，下一个请求才会开始传输。

HTTP/2.0 的多路复用则是利用分帧数据流，把HTTP协议分解为胡不依赖的帧（为每个帧标序发送，接收回来的时候按序重组），进而可以乱序发送避免一定程度上的队首阻塞问题。

但是无论是 HTTP/1.1 还是 HTTP/2.0，response响应的处理顺序总是需要跟request的请求顺序保持一致的。假如某个请求的response响应较慢，还是同样会有阻塞的问题。主要是受限于HTTP底层的传输协议是TCP，没办法完全解决线头阻塞的问题。

Reference

HTTP/2 服务器推送（Server Push）教程

gRPC系列(三) 如何借助HTTP2实现传输

思考gRPC ：为什么是HTTP/2

HTTP/2 资料汇总

深入剖析HTTP3协议

HTTP1.0、1.1、2.0协议的特性及区别

SPDY与QUIC

解密SPDY协议

3.3.2 - HTTPS加密原理

背景

HTTP的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以需要对信息进行加密。最容易理解的就是对称加密。

对称加密

定义

一个密钥可以加密一段信息，也可以对加密后的信息进行解密。

可行性

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

但是最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后它就能用密钥解开双方传输的任何内容，所以这么做当然不行。

非对称加密

简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样私钥加密的内容只有公钥能解开。

可行性

服务端到浏览器链路的安全

鉴于非对称加密的机制，简单的思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。

然而反过来由服务器到浏览器的这条路怎么保障安全？即服务器怎么将公钥安全地传给浏览器不被劫持。如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那它也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性。

中间人攻击

某网站有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。

数字证书

简介

为了解决浏览器收到的公钥一定是该网站的公钥，CA机构给网站颁发的“身份证”即数字证书用来证明网站身份。

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。

防伪

这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？

把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名。

数字签名

数字签名的制作过程：

CA机构拥有非对称加密的私钥和公钥。
CA机构对证书明文数据T进行hash。
对hash后的值用私钥加密，得到数字签名S。明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

拿到证书，得到明文T，签名S。
用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
用证书里指明的hash算法对明文T进行hash得到T’。显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。为什么能保证证书可信？

没有私钥无法篡改签名
无法掉包证书，因为证书里有域名，不一致则无法掉包

HTTPS验证流程

1、客户端发起一个http请求，告诉服务器自己支持哪些hash算法。

2、服务端把自己的信息以数字证书的形式返回给客户端（证书内容有密钥公钥，网站地址，证书颁发机构，失效日期等）。证书中有一个公钥来加密信息，私钥由服务器持有。

3、验证证书的合法性

客户端收到服务器的响应后会先验证证书的合法性（证书中包含的地址与正在访问的地址是否一致，证书是否过期）。

4、生成随机密码（RSA签名）

如果验证通过，或用户接受了不受信任的证书，浏览器就会生成一个随机的对称密钥（session key）并用公钥加密，让服务端用私钥解密，解密后就用这个对称密钥进行传输了，并且能够说明服务端确实是私钥的持有者。

5、生成对称加密算法

验证完服务端身份后，客户端生成一个对称加密的算法和对应密钥，以公钥加密之后发送给服务端。此时被黑客截获也没用，因为只有服务端的私钥才可以对其进行解密。之后客户端与服务端可以用这个对称加密算法来加密和解密通信内容了。

Reference

彻底搞懂HTTPS的加密原理

4 - IO

Introduction

I/O知识介绍

4.1 - Java NIO核心知识

简介

NIO（Non-blocking I/O，在Java领域，也称为New I/O），是一种同步非阻塞的I/O模型，也是I/O多路复用的基础。IO多路复用，一言以蔽之，就是**"复用"一个线程或一个进程，同时监测若干个（"多路"）文件描述符是否可以执行IO操作的能力。** 在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。**I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。**与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统维护的工作量，节省了系统资源。

IO多路复用的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。

关于 Java NIO 相关的核心，总的来看包含以下三点，分别是：

Channel
Buffer
Selector

BIO

通过 socket 通信，实际上就是通过文件描述符 fd 读写文件

C10k问题

C10K 就是 Client 10000 问题，即「在同时连接到服务器的客户端数量超过 10000 个的环境中，即便硬件性能足够，依然无法正常提供服务」，简而言之，就是单机1万个并发连接问题。这个概念最早由 Dan Kegel 提出并发布于其个人站点（ http://www.kegel.com/c10k.html ）

设计 Unix 的 PID 的时候，采用了有符号的16位整数，这就导致一台计算机上能够创建出来的进程无法超过32767个。

Channel

Channel 就是通道。可以往通道里写数据、读数据。它是双向的，与之配套的是 Buffer，即要往一个通道里写数据，必须要将数据写到一个 Buffer 中，然后写到通道里。同样，从通道里读数据，必须将通道的数据先读取到一个 Buffer 中，然后再操作。

在 NIO 中 Channel 有多种类型：

SocketChannel
ServerSocketChannel
DatagramChannel
FileChannel

SocketChannel

对标 Socket，可以直接将它看做所建立的连接。通过 SocketChannel ，可以利用 TCP 协议进行读写网络数据。

SocketChannel 主要在两个地方出现：

客户端，客户端创建一个 SocketChannel 用于连接至远程的服务端。
服务端，服务端利用 ServerSocketChannel 接收新连接之后，为其创建一个 SocketChannel 。随后，客户端和服务端就可以通过这两个 SocketChannel 相互发送和接收数据。

ServerSocketChannel

服务端创建的 Socket，可以对标 ServerSocket。

主要是用来接待新连接，监听新建连的 TCP 连接，为新进一个连接创建对应的 SocketChannel。然后通过新建的 SocketChannel 可以进行网络数据的读写，与对端交互。

ServerSocketChannel 主要出现在一个地方：服务端。

服务端需要绑定一个端口，然后监听新连接的到来，这个活儿就由 ServerSocketChannel 来干。

服务端内常常会利用一个线程，一个死循环，不断地接收新连接的到来。

1
2
3
4
5
6
7
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
...
while(true) {
  // 接收新的连接
  SocketChannel socketChannel = serverSocketChannel.accept();
  ...
}

DatagramChannel

Datagram（数据报），即 UDP 协议，是无连接协议。利用 DatagramChannel 可以直接通过 UDP 进行网络数据的读写。

FileChannel

文件通道，用来进行文件的数据读写。

我们日常开发主要是基于 TCP 协议，所以我们把精力放在 SocketChannel 和 ServerSocketChannel 上即可。

Buffer

Buffer 就是内存中可以读写的一块地方，叫缓冲区，用于缓存数据。

其并没有太多原理可介绍，主要关注 Java NIO Buffer 的 API 即可。当然其 API 有很多优化之处，所以 Netty 没用 Java NIO Buffer 而是自行实现了一个 Buffer，叫 ByteBuf。

为什么 Channel 必须和 Buffer 搭配使用？

其实网络数据是面向字节的，但是读写的数据往往是多字节的，假设不用 Buffer 那需要一个字节一个字节的调用读和调用写，非常麻烦。所以搞个 Buffer 将数据拢一拢，这样之后的调用才能更好地处理完整的数据，方便异步的处理等等。

Selector

Selector 是 I/O 多路复用的核心组件。

一个 Selector 上可以注册多个 Channel ，从上面已经知道一个 Channel 就对应了一个连接，因此一个 Selector 可以管理多个 Channel 。

当任意 Channel 发生读写事件时，通过 Selector.select() 就可以捕捉到事件的发生，因此可以利用一个线程，死循环的调用 Selector.select()，这样可以利用一个线程管理多个连接，减少了线程数，减少了线程的上下文切换和节省了线程资源。这就是 Selector 的核心功能。

具体详细步骤：

创建一个 Selector
1
Selector selector = Selector.open();
将要被管理的 Channel 注册到 Selector 上，并声明感兴趣的事件
1
SelectionKey key = channel.register(selector, Selectionkey.OP_READ | Selectionkey.OP_WRITE);

事件类型：

1
2
3
4
public static final in OP_READ = 1 << 0;
public static final in OP_WRITE = 1 << 2;
public static final in OP_CONNECT = 1 << 3;
public static final in OP_ACCEPT = 1 << 4;

当 Channel 发生读或写事件，调用 Selector.select() 就可以得知有事件发生。该函数具体有3个重载方法：
- int selectNow()：不论是否有误事件发生，立即返回
- int select(long timeout)：至多阻塞 timeout 时间（或被唤醒），如果提前有事件发生则提前返回
- int select()：一直阻塞，直到有事件发生（或被唤醒）。返回值就是就绪的通道数，一般判断大于 0 即可后续的操作，即调用：

1
Set selectedKeys = selector.selectedKeys();

获得一个类型为 Set 的 selectedKeys 集合。可以通过 selectedKey 得知当前发生的是什么事件，有 isAcceptable、isReadable 等等。

还能获得对应 channel 进行相应的读写操作，还有获取 attachment 等等。

所以得到了 selectedKeys 就可以通过迭代器遍历所有发生事件的连接，然后进行操作：

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
while(true) {
 int readyNum = selector.select();
 if (readyNum == 0) {
    continue;
 }
 Set selectedKeys = selector.selectedKeys();
 Iterator keyIterator = selectedKeys.iterator();
 while(keyIterator.hasNext()) {
    SelectionKey key = keyIterator.next();
    if(key.isAcceptable()) {
        // a connection was accepted by a ServerSocketChannel.
    } else if (key.isConnectable()) {
        // a connection was established with a remote server.
    } else if (key.isReadable()) {
        // a channel is ready for reading
    } else if (key.isWritable()) {
        // a channel is ready for writing
    }
    keyIterator.remove(); //执行完毕之后，需要在循环内移除自己
 }
}

还有个方法是 Selector.wakeup()，可以唤醒阻塞着的 Selector。

前提：如果 Channel 要和 Selector 搭配，那它必须得是非阻塞的，即配置：

1
channel.configureBlocking(false);

从上面的分析，可以得知 Selector 处理事件的时候必须快，如果长时间处理某个事件，那么注册到 Selector 上的其他连接的事件就不会被及时处理，造成客户端阻塞。

4.2 - Netty服务器启动源码分析

Tips

netty-xxx-sources.jar包中会有个example文件夹，里面有netty的使用案例。本文可以以 EchoServer为例

IDEA查看xx-sources.jar

sources.jar包可以通过 Moudels -> 添加 -> 右键菜单 -> Copy to Module Libraries -> Copy library files to -> 项目的lib中可以看到该jar包

可以将demo的代码拷贝到项目中运行debug源码

Demo

EchoServer Demo

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public static void main(String[] args) throws Exception {
    // Configure SSL.
    final SslContext sslCtx;
    if (SSL) {
        SelfSignedCertificate ssc = new SelfSignedCertificate();
        sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();
    } else {
        sslCtx = null;
    }
    // Configure the server.
    EventLoopGroup bossGroup = new NioEventLoopGroup(1);
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    try {
        ServerBootstrap b = new ServerBootstrap();
        b.group(bossGroup, workerGroup)
         .channel(NioServerSocketChannel.class)
         // option添加TCP参数
         .option(ChannelOption.SO_BACKLOG, 100)
         .handler(new LoggingHandler(LogLevel.INFO))
         .childHandler(new ChannelInitializer<SocketChannel>() {
             @Override
             public void initChannel(SocketChannel ch) throws Exception {
                 ChannelPipeline p = ch.pipeline();
                 if (sslCtx != null) {
                     p.addLast(sslCtx.newHandler(ch.alloc()));
                 }
                 //p.addLast(new LoggingHandler(LogLevel.INFO));
                 p.addLast(new EchoServerHandler());
             }
         });
        // Start the server.
        ChannelFuture f = b.bind(PORT).sync();
        // Wait until the server socket is closed.
        f.channel().closeFuture().sync();
    } finally {
        // Shut down all event loops to terminate all threads.
        bossGroup.shutdownGracefully();
        workerGroup.shutdownGracefully();
    }
}

普通Demo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
public static void main(String[] args) throws Exception {
        EventLoopGroup bossGroup = new NioEventLoopGroup(1);
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .handler(new SimpleServerHandler())
                    .childHandler(new SimpleServerInitializer())
                    .option(ChannelOption.SO_BACKLOG, 128)
                    .childOption(ChannelOption.SO_KEEPALIVE, true);
            ChannelFuture f = b.bind(8989).sync();
            f.channel().closeFuture().sync();
        } finally {
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }

以下源码以 netty-4.1.1-Final.jar为例

NioEventLoopGroup

以下根据 EchoServer 的main 的入口源码进行分析

1
2
3
4
// io.netty.example.echo.EchoServer#main
// Configure the server.
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();

MultithreadEventExecutorGroup

NioEventLoopGroup继承了该类，其初始化主要该类的初始化过程。

默认线程个数

通过对 NioEventLoopGroup() 的跟踪，发现如果未指定线程个数，会调用MultithreadEventLoopGroup构造函数，默认使用 DEFAULT_EVENT_LOOP_THREADS ，而该参数的初始化是：

1
2
3
4
5
6
// io.netty.channel.MultithreadEventLoopGroup#
// MultithreadEventLoopGroup(int, java.util.concurrent.Executor, java.lang.Object...)
private static final int DEFAULT_EVENT_LOOP_THREADS = Math.max(1, SystemPropertyUtil.getInt("io.netty.eventLoopThreads", Runtime.getRuntime().availableProcessors() * 2));
protected MultithreadEventLoopGroup(int nThreads, Executor executor, Object... args) {
    super(nThreads == 0 ? DEFAULT_EVENT_LOOP_THREADS : nThreads, executor, args);
}

参数说明

该类的构造方法才是 NioEventLoopGroup 真正的构造方法，这里可以看做是一个模板方法（设计模式）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
// io.netty.util.concurrent.MultithreadEventExecutorGroup
/**
 * Create a new instance.
 *
 * @param nThreads          the number of threads that will be used by this instance.
 使用的线程数，默认 处理器个数*2
 * @param executor          the Executor to use, or {@code null} if the default should be used.
 执行器，如果传入null，则采用Netty默认的线程工厂和默认的执行器ThreadPerTaskExecutor
 * @param chooserFactory    the {@link EventExecutorChooserFactory} to use.
 单例new DefaultEventExecutorChooserFactory()
 * @param args              arguments which will passed to each {@link #newChild(Executor, Object...)} call
 在创建执行器的时候传入固定参数
 */
protected MultithreadEventExecutorGroup(int nThreads, Executor executor,
                                        EventExecutorChooserFactory chooserFactory, Object... args)

初始化过程

往下可以看到会创建 EventExecutor 数组 children

可以通过快捷键 ctrl + H（mac系统）查看类的 EventExecutor 类的层次结构，可以发现 EventExecutor <- SingleThreadEventLoop <- NioEventLoop，这里每个元素的类型是 NioEventLoop。

该函数中还对每个元素加了监听器

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
protected MultithreadEventExecutorGroup(int nThreads, Executor executor,
                                        EventExecutorChooserFactory chooserFactory, Object... args) {
    if (nThreads <= 0) {
        throw new IllegalArgumentException(String.format("nThreads: %d (expected: > 0)", nThreads));
    }
    if (executor == null) {
        executor = new ThreadPerTaskExecutor(newDefaultThreadFactory());
    }
    // 创建指定线程数的执行器数组
    children = new EventExecutor[nThreads];
    // 初始化线程数组
    for (int i = 0; i < nThreads; i ++) {
        boolean success = false;
        try {
            // 创建 new NioEventLoop
            children[i] = newChild(executor, args);
            success = true;
        } catch (Exception e) {
            // TODO: Think about if this is a good exception type
            throw new IllegalStateException("failed to create a child event loop", e);
        } finally {
            // 创建失败，优雅关闭之前几个成功创建的 NioEventLoop
            if (!success) {
                for (int j = 0; j < i; j ++) {
                    children[j].shutdownGracefully();
                }
                for (int j = 0; j < i; j ++) {
                    EventExecutor e = children[j];
                    try {
                        while (!e.isTerminated()) {
                            e.awaitTermination(Integer.MAX_VALUE, TimeUnit.SECONDS);
                        }
                    } catch (InterruptedException interrupted) {
                        // Let the caller handle the interruption.
                        Thread.currentThread().interrupt();
                        break;
                    }
                }
            }
        }
    }
    chooser = chooserFactory.newChooser(children);
    final FutureListener<Object> terminationListener = new FutureListener<Object>() {
        @Override
        public void operationComplete(Future<Object> future) throws Exception {
            if (terminatedChildren.incrementAndGet() == children.length) {
                terminationFuture.setSuccess(null);
            }
        }
    };
    // 为每个单例线程池添加一个关闭监听器
    for (EventExecutor e: children) {
        e.terminationFuture().addListener(terminationListener);
    }
    Set<EventExecutor> childrenSet = new LinkedHashSet<EventExecutor>(children.length);
    // 将所有的单例线程池添加到一个 HashSet 中
    Collections.addAll(childrenSet, children);
    readonlyChildren = Collections.unmodifiableSet(childrenSet);
}

分析说明： 1、如果 executor 是null，创建一个默认的 ThreadPerTaskExecutor，使用Netty默认的线程工厂

2、根据传入的线程数（CPU*2）创建一个线程池的（单例线程池）数组

3、循环填充数组中元素。如果异常，则关闭所有的单例线程池

4、根据线程选择工程创建一个线程选择器

5、为每一个单例线程池添加一个关闭监听器

6、将所有单例线程池添加到一个 HashSet 中

NioEventLoop

1
2
3
4
5
6
7
8
9
// io.netty.channel.nio.NioEventLoop#NioEventLoop
NioEventLoop(NioEventLoopGroup parent, ThreadFactory threadFactory, SelectorProvider selectorProvider) {
    super(parent, threadFactory, false);
    if (selectorProvider == null) {
        throw new NullPointerException("selectorProvider");
    }
    provider = selectorProvider;
    selector = openSelector();
}

父类SingleThreadEventExecutor

1
// 

该初始化函数主要做了两件事： 1、利用ThreadFactory创建来一个Thread，传入了一个Runnable对象，该Runnable重写的run代码比较长，不过重点仅仅是调用NioEventLoop类的run方法。

2、使用LinkedBlockingQueue类初始化taskQueue 。

绑定group

用于后期引导使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// io.netty.bootstrap.ServerBootstrap#
// group(io.netty.channel.EventLoopGroup, io.netty.channel.EventLoopGroup)
public ServerBootstrap group(EventLoopGroup parentGroup, EventLoopGroup childGroup) {
    super.group(parentGroup);
    if (childGroup == null) {
        throw new NullPointerException("childGroup");
    }
    if (this.childGroup != null) {
        throw new IllegalStateException("childGroup set already");
    }
    this.childGroup = childGroup;
    return this;
}

添加channel

其中参数一个Class对象，引导类将通过这个Class对象反射创建 ChannelFactory。

1
2
3
4
5
6
7
// io.netty.bootstrap.AbstractBootstrap#channel
public B channel(Class<? extends C> channelClass) {
    if (channelClass == null) {
        throw new NullPointerException("channelClass");
    }
    return channelFactory(new ReflectiveChannelFactory<C>(channelClass));
}

channel的创建

1
2
3
4
5
6
7
// io.netty.bootstrap.AbstractBootstrap#initAndRegister
final ChannelFuture initAndRegister() {
    final Channel channel = channelFactory.newChannel();
    try {
        init(channel);
    } catch (Throwable t) {
    

可以通过 debug 或查看 initAndRegister 方法调用层次

日志处理器handler

添加服务器专属日志处理器handler。

注意是 ServerSocketChannel

1
.handler(new LoggingHandler(LogLevel.INFO))

xxServerHandler

添加SocketChannel的handler

注意不是 ServerSocketChannel

1
.childHandler(xx)

这是一个普通的处理器类，用于处理客户端发送来的消息，入口函数中在 ServerBootstrap 的 .chanldHanlder 中添加该hanlder。

这里处理主要分析客户端发送内容来解析、打印、响应发送字符串给客户端的过程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
// io.netty.example.echo.EchoServerHandler
@Sharable
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        ctx.write(msg);
    }
    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) {
        ctx.flush();
    }
    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        // Close the connection when an exception is raised.
        cause.printStackTrace();
        ctx.close();
    }
}

ServerBootstrap

try块中创建了一个 ServerBootstrap 对象，它是一个引导类，用于启动服务器和引导整个程序的初始化。它和 ServerChannel 关联，而 ServerChannel 继承了 Channel。

1
2
3
4
5
6
7
try {
    ServerBootstrap b = new ServerBootstrap();
    b.group(bossGroup, workerGroup)
     .channel(NioServerSocketChannel.class)
     .option(ChannelOption.SO_BACKLOG, 100)
     .handler(new LoggingHandler(LogLevel.INFO))
     .childHandler(xxxxx);

类的继承关系

ServerBootstrap -> AbstractBootstrap --> Cloneable

空构造函数

但是有默认的成员变量，会直接初始化

1
2
3
4
5
6
7
8
// io.netty.bootstrap.ServerBootstrap
private final Map<ChannelOption<?>, Object> childOptions = new LinkedHashMap<ChannelOption<?>, Object>();
private final Map<AttributeKey<?>, Object> childAttrs = new LinkedHashMap<AttributeKey<?>, Object>();
// config很重要，后面会用到
private final ServerBootstrapConfig config = new ServerBootstrapConfig(this);
private volatile EventLoopGroup childGroup;
private volatile ChannelHandler childHandler;
public ServerBootstrap() { }

构造过程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
 .channel(NioServerSocketChannel.class)
 .option(ChannelOption.SO_BACKLOG, 100)
 .handler(new LoggingHandler(LogLevel.INFO))
 .childHandler(new ChannelInitializer<SocketChannel>() {
     @Override
     public void initChannel(SocketChannel ch) throws Exception {
         ChannelPipeline p = ch.pipeline();
         if (sslCtx != null) {
             p.addLast(sslCtx.newHandler(ch.alloc()));
         }
         //p.addLast(new LoggingHandler(LogLevel.INFO));
         p.addLast(new EchoServerHandler());
     }
 });

分析说明： 1、链式调用：group 方法，将boss和worker传入，boss赋值给parentGroup属性，worker赋值给childGroup属性

2、channel 方法传入 NioServerSocketChannel.class 对象。会根据这个创建 channel 对象

3、option 方法传入TCP参数，放在一个LinkedHashMap中

4、handler 方法传入一个hanlder，该hanler专属于 ServerSocketChannel 而不是 SocketChannel

5、childHandler 传入一个handler，这个handler将会在每个客户端连接的时候调用。供 SocketChannel 使用。

绑定端口

服务器在bind方法中启动完成的

1
2
3
// io.netty.example.echo.EchoServer#main
// Start the server.
ChannelFuture f = b.bind(PORT).sync();

bind方法

1
2
3
4
5
6
7
8
// io.netty.bootstrap.AbstractBootstrap
public ChannelFuture bind(SocketAddress localAddress) {
    validate();
    if (localAddress == null) {
        throw new NullPointerException("localAddress");
    }
    return doBind(localAddress);
}

核心代码为doBind方法

validate方法

该方法主要检查了两个参数，一个是group，一个是channelFactory。

这两个将bossGroup赋值给了group，将BootstrapChannelFactory赋值给了channelFactory。赋值如下：

1
2
3
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
  .channel(NioServerSocketChannel.class)

doBind方法

核心是两个方法 initAndRegister 和 doBind0

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// io.netty.bootstrap.AbstractBootstrap#doBind
private ChannelFuture doBind(final SocketAddress localAddress) {
    final ChannelFuture regFuture = initAndRegister(); // 1
    final Channel channel = regFuture.channel();
    if (regFuture.cause() != null) { // 2
        return regFuture;
    }
    if (regFuture.isDone()) { // 3
        // At this point we know that the registration was complete and successful.
        ChannelPromise promise = channel.newPromise();
        doBind0(regFuture, channel, localAddress, promise);
        return promise;
    } else { // 4
        // Registration future is almost always fulfilled already, but just in case it's not.
        final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
        regFuture.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture future) throws Exception {
                Throwable cause = future.cause();
                if (cause != null) {
                    // Registration on the EventLoop failed so fail the ChannelPromise directly to not cause an
                    // IllegalStateException once we try to access the EventLoop of the Channel.
                    promise.setFailure(cause);
                } else {
                    // Registration was successful, so set the correct executor to use.
                    // See https://github.com/netty/netty/issues/2586
                    promise.registered();
                    doBind0(regFuture, channel, localAddress, promise);
                }
            }
        });
        return promise;
    }
}

doBind函数是分析重点，主要工作如下： 1、initAndRegister()方法得到一个ChannelFuture的实例regFuture。

2、regFuture.cause()方法判断是否在执行initAndRegister方法时产生来异常。如果产生异常直接返回，如果没有则进行第3步。

3、通过regFuture.isDone()来判断initAndRegister方法是否执行完毕，如果执行完成返回true，然后调用doBind0进行socket绑定。如果没有执行完成则返回false进行第4步。

4、regFuture会添加一个ChannelFutureListener监听，当initAndRegister执行完成时，调用operationComplete方法并执行doBind0进行socket绑定。

第3、4步同一个目的：调用doBind0方法进行socket绑定。

initAndRegister

1
2
3
4
5
6
7
8
// io.netty.bootstrap.AbstractBootstrap#initAndRegister
final ChannelFuture initAndRegister() {
    final Channel channel = channelFactory.newChannel();
    try {
        init(channel);
    } catch (Throwable t) {
    }
    ChannelFuture regFuture = group().register(channel);

这里初始化 children channel。

newChannel分析

上面介绍过，channelFactory 是通过如下方式赋值的

1
2
3
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
  .channel(NioServerSocketChannel.class)

channelFactory.newChannel() 方法的作用是通过 ServerBootstrap 的通道工厂反射创建一个 NioServerSocketChannel。分析 NioServerSocketChannel 的构造函数：

0、继承关系

NioServerSocketChannel -> AbstractNioMessageChannel -> AbstractNioChannel -> AbstractChannel

1、通过NIO的 SelectorProvider 的 openServerSocketChannel 方法可以得到JDK的 channel，目的是让Netty包装JDK的channel

2、调用父类设置到ch属性中，并设置为非阻塞

1
2
3
4
5
6
7
// io.netty.channel.nio.AbstractNioChannel#AbstractNioChannel
protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) {
    super(parent);
    this.ch = ch;
    this.readInterestOp = readInterestOp;
    try {
        ch.configureBlocking(false);

3、设置config属性

1
2
3
4
5
// io.netty.channel.socket.nio.NioServerSocketChannel#NioServerSocketChannel
public NioServerSocketChannel(ServerSocketChannel channel) {
    super(null, channel, SelectionKey.OP_ACCEPT);
    config = new NioServerSocketChannelConfig(this, javaChannel().socket());
}

NioServerSocketChannelConfig 对象，用于对外展示一些配置。 4、调用父构造函数设置unsafe属性、pipeline属性、ChannelId等

1
2
3
4
5
6
7
// io.netty.channel.AbstractChannel#AbstractChannel
protected AbstractChannel(Channel parent) {
    this.parent = parent;
    id = newId();
    unsafe = newUnsafe();
    pipeline = newChannelPipeline();
}

NioMessageUnsafe 是在 AbstractNioMessageChannel 中创建的，用于操作消息。（cmd+F12查看NioServerSocketChannel及其父类的newUnsafe方法） DefaultChannelPipeline 管道，是个双向链表结构，用于过滤所有的进出的消息。

init分析

1、init方法是AbstractBootstrap的抽象方法，具体由 ServerBootstrap 实现（上面分析b对象是new ServerBootstrap）

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// io.netty.bootstrap.ServerBootstrap#init
@Override
void init(Channel channel) throws Exception {
    final Map<ChannelOption<?>, Object> options = options0();
    synchronized (options) {
        channel.config().setOptions(options);
    }
    final Map<AttributeKey<?>, Object> attrs = attrs0();
    synchronized (attrs) {
        for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
            @SuppressWarnings("unchecked")
            AttributeKey<Object> key = (AttributeKey<Object>) e.getKey();
            channel.attr(key).set(e.getValue());
        }
    }
    ChannelPipeline p = channel.pipeline();
    final EventLoopGroup currentChildGroup = childGroup;
    final ChannelHandler currentChildHandler = childHandler;
    final Entry<ChannelOption<?>, Object>[] currentChildOptions;
    final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
    synchronized (childOptions) {
        currentChildOptions = childOptions.entrySet().toArray(newOptionArray(childOptions.size()));
    }
    synchronized (childAttrs) {
        currentChildAttrs = childAttrs.entrySet().toArray(newAttrArray(childAttrs.size()));
    }
    p.addLast(new ChannelInitializer<Channel>() {
        @Override
        public void initChannel(Channel ch) throws Exception {
            ChannelPipeline pipeline = ch.pipeline();
            ChannelHandler handler = config.handler();
            if (handler != null) {
                pipeline.addLast(handler);
            }
            pipeline.addLast(new ServerBootstrapAcceptor(
                    currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
        }
    });
}

2、设置 NioServerSocketChannel 的TCP属性，options 3、由于 LinkedHashMap 是非线程安全的，使用同步进行处理

4、对 NioServerSocketChannel 的 ChannelPipeline 添加 ChannelInitializer 处理器，重写 initChannel 方法，该方法通过 addList 向 serverChannel 的流水线处理器重加了一个 ServerBootstrapAcceptor，这是一个接入器，专门接受新请求，并扔给某个事件循环器

5、可以分析出，init 方法的核心作用是和 ChannelPipeline 相关

6、从 NioServerSocketChannel 的初始化过程可以分析出：pipeline是一个双向链表，并且本身初始化了 head 和 tail。ChannelPipeline 的 addLast 方法是将 hanlder 插入到 tail 的前面，tail永远在后面，用于做一些系统的固定工作。

总结

init只是初始化一些基本的配置和属性，以及在pipeline加入一个接入器，用来专门接受新请求，而并没有启动服务。

分析addLast方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// io.netty.channel.DefaultChannelPipeline#addLast(io.netty.util.concurrent.EventExecutorGroup, java.lang.String, io.netty.channel.ChannelHandler)
@Override
public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
    final AbstractChannelHandlerContext newCtx;
    synchronized (this) {
        checkMultiplicity(handler);

        newCtx = newContext(group, filterName(name, handler), handler);

        addLast0(newCtx);

        if (!registered) {
            callHandlerCallbackLater(newCtx, true);
            return this;
        }

        EventExecutor executor = newCtx.executor();
        if (!executor.inEventLoop()) {
            executor.execute(new OneTimeTask() {
                @Override
                public void run() {
                    callHandlerAdded0(newCtx);
                }
            });
            return this;
        }
    }
    callHandlerAdded0(newCtx);
    return this;
}

addLast 最终会调用 addLast0 方法

1
2
3
4
5
6
7
8
// io.netty.channel.DefaultChannelPipeline#addLast0
private void addLast0(AbstractChannelHandlerContext newCtx) {
    AbstractChannelHandlerContext prev = tail.prev;
    newCtx.prev = prev;
    newCtx.next = tail;
    prev.next = newCtx;
    tail.prev = newCtx;
}

addList结论： 1、addLast 方法在 DefaultChannelPipeline 类中

2、addList 方法是 pipeline 方法的核心

3、检查该 handler 是否符合标准

4、创建一个 AbstractChannelHandlerContext 对象

说明：ChannelHandlerContext 对象是 ChannelHandler 和 ChannelPipeline 之间的关联，每当有 ChannelHandler 添加到 Pipeline 中时，都会创建Context。

Context的主要功能是管理他所关联的 Handler 和同一个 Pipeline 中的其他 Handler 之间的交互。

5、将 Context 添加到链表中。也就是追加到 tail 节点的前面

6、最后，同步或异步或晚点异步的调用 callHandlerAdded 方法

register channel

继续看 initAndRegister 中的 register

1
2
// io.netty.bootstrap.AbstractBootstrap#initAndRegister
ChannelFuture regFuture = group().register(channel);

由上文知道这里group为MultithreadEventLoopGroup，其register方法为

1
2
3
4
5
// io.netty.channel.MultithreadEventLoopGroup#register
@Override
public ChannelFuture register(Channel channel) {
    return next().register(channel);
}

这里 next() 可以跟踪到父类初始化 chooser 根据是 executors.length 选择，next方法对length做了一点区别处理。 next的主要作用是因为 NioEventLoopGroup 中维护着多个 NioEventLoop，next方法回调用chooser策略找到下一个 NioEventLoop，并执行该对象的register方法进行注册。

register 实际调用 SingleThreadEventLoop

1
2
3
4
5
6
7
// io.netty.channel.SingleThreadEventLoop#register
@Override
public ChannelFuture register(final ChannelPromise promise) {
    ObjectUtil.checkNotNull(promise, "promise");
    promise.channel().unsafe().register(this, promise);
    return promise;
}

unsafe上文分析了是 NioMessageUnsafe，unsafe().register方法实际调用 AbstractUnsafe 的方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// io.netty.channel.AbstractChannel.AbstractUnsafe#register
@Override
public final void register(EventLoop eventLoop, final ChannelPromise promise) {
    if (eventLoop == null) {
        throw new NullPointerException("eventLoop");
    }
    // 判断该 channel 是否已经被注册到 EventLoop 中
    if (isRegistered()) {
        promise.setFailure(new IllegalStateException("registered to an event loop already"));
        return;
    }
    if (!isCompatible(eventLoop)) {
        promise.setFailure(
                new IllegalStateException("incompatible event loop type: " + eventLoop.getClass().getName()));
        return;
    }
    // 将 eventLoop 设置到 NioServerSocketChannel 中
    AbstractChannel.this.eventLoop = eventLoop;
    // 判断当前线程是否为该 EventLoop 中拥有的线程，
    // 如果是直接注册，否则添加一个任务到该线程中
    if (eventLoop.inEventLoop()) {
        register0(promise);
    } else {
        try {
            // 非常重要
            eventLoop.execute(new OneTimeTask() {
                @Override
                public void run() {
                    register0(promise);
                }
            });
        } catch (Throwable t) {
            logger.warn(
                    "Force-closing a channel whose registration task was not accepted by an event loop: {}",
                    AbstractChannel.this, t);
            closeForcibly();
            closeFuture.setClosed();
            safeSetFailure(promise, t);
        }
    }
}

基本逻辑如下： 1、通过 eventLoop.inEventLoop() 判断当前线程是否为该 EventLoop 中拥有的线程，如果是直接注册，否则说明该 EventLoop 在等待并没有执行权。

2、提交一个任务到该线程中，等该 EventLoop 的线程有执行权就会执行该任务（负责调用调用 register0 方法）

重点为 register0 方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// io.netty.channel.AbstractChannel.AbstractUnsafe#register0
private void register0(ChannelPromise promise) {
    try {
        xxxx
        doRegister();
        neverRegistered = false;
        registered = true;

        safeSetSuccess(promise);
        pipeline.fireChannelRegistered();
        xxx
}

doRegister方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
// io.netty.channel.nio.AbstractNioChannel#doRegister
@Override
protected void doRegister() throws Exception {
    boolean selected = false;
    for (;;) {
        try {
            selectionKey = javaChannel().register(eventLoop().selector, 0, this);
            return;
        } catch (CancelledKeyException e) {
            if (!selected) {
                // Force the Selector to select now as the "canceled" SelectionKey may still be
                // cached and not removed because no Select.select(..) operation was called yet.
                eventLoop().selectNow();
                selected = true;
            } else {
                // We forced a select operation on the selector before but the SelectionKey is still cached
                // for whatever reason. JDK bug ?
                throw e;
            }
        }
    }
}

经上文 newChannel 分析，知道这里javaChannel方法返回的ch为实例化NioServerSocketChannel时产生的 SocketChannelImpl实例，并设置为非阻塞的。

总结

1、initAndRegister 初始化 NioServerSocketChannel 通道并注册各个 handler，返回一个 future

2、通过 ServerBootrap 的通道工厂反射创建一个 NioServerSocketChannel

3、init初始化 NioServerSocketChannel

4、group().register(channel) 通过 ServerBootstrap 的 bossGroup 注册 NioServerSocketChannel

5、最后返回这个异步执行的占位符 regFuture

dobind0方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
// io.netty.bootstrap.AbstractBootstrap#doBind0
private static void doBind0(
        final ChannelFuture regFuture, final Channel channel,
        final SocketAddress localAddress, final ChannelPromise promise) {

    // This method is invoked before channelRegistered() is triggered.  Give user handlers a chance to set up
    // the pipeline in its channelRegistered() implementation.
    channel.eventLoop().execute(new OneTimeTask() {
        @Override
        public void run() {
            if (regFuture.isSuccess()) {
                channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
            } else {
                promise.setFailure(regFuture.cause());
            }
        }
    });
}

这里主要是提交了一个任务到 NioEventLoop 线程中。提交的任务执行后，然后执行 channel.bind 方法并添加事件，完成 channel 与端口的绑定

executor方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
// io.netty.util.concurrent.SingleThreadEventExecutor#execute
@Override
public void execute(Runnable task) {
    if (task == null) {
        throw new NullPointerException("task");
    }
    boolean inEventLoop = inEventLoop();
    if (inEventLoop) {
        addTask(task);
    } else {
        startThread();
        addTask(task);
        if (isShutdown() && removeTask(task)) {
            reject();
        }
    }

    if (!addTaskWakesUp && wakesUpForTask(task)) {
        wakeup(inEventLoop);
    }
}

inEventLoop 方法判断当前线程是否为该 NioEventLoop 关联的线程，如果是添加任务到任务队列中，不是则先启动线程，然后添加任务到任务队列中去

channel.bind

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// io.netty.channel.AbstractChannelHandlerContext#bind
@Override
public ChannelFuture bind(final SocketAddress localAddress, final ChannelPromise promise) {
    if (localAddress == null) {
        throw new NullPointerException("localAddress");
    }
    if (!validatePromise(promise, false)) {
        // cancelled
        return promise;
    }
    final AbstractChannelHandlerContext next = findContextOutbound();
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        next.invokeBind(localAddress, promise);
    } else {
        safeExecute(executor, new OneTimeTask() {
            @Override
            public void run() {
                next.invokeBind(localAddress, promise);
            }
        }, promise, null);
    }
    return promise;
}

findContextOutbound 就是在pipeline所持有的以 AbstractChannelHandlerContext 为节点的双向链表中从尾节点tail开始向前寻找第一个outbound=true的handler节点。 DefaultChannelPipeline 构造器中, 会实例化head和tail两个对象，形成了双向链表的头和尾。 head 是 HeadContext 的实例，实现了 ChannelOutboundHandler 接口和 ChannelInboundHandler 接口，它的 outbound 字段为 true。而tail 是 TailContext 的实例，实现了ChannelInboundHandler 接口，它的 outbound 字段为 false，inbound 字段为true。因此 findContextOutbound方法找到的 AbstractChannelHandlerContext 对象其实就是 head。

然后调用 next.invokeBind 方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// io.netty.channel.AbstractChannelHandlerContext#invokeBind
private void invokeBind(SocketAddress localAddress, ChannelPromise promise) {
    if (isAdded()) {
        try {
            ((ChannelOutboundHandler) handler()).bind(this, localAddress, promise);
        } catch (Throwable t) {
            notifyOutboundHandlerException(t, promise);
        }
    } else {
        bind(localAddress, promise);
    }
}

继续看 bind 方法，这里是 HeadContext 的

1
2
3
4
5
6
7
// io.netty.channel.DefaultChannelPipeline.HeadContext#bind
@Override
public void bind(
        ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)
        throws Exception {
    unsafe.bind(localAddress, promise);
}

这里的 unsafe 是在 HeadContext 构造函数中赋值的

1
2
3
4
5
6
// io.netty.channel.DefaultChannelPipeline.HeadContext#HeadContext
HeadContext(DefaultChannelPipeline pipeline) {
    super(pipeline, null, HEAD_NAME, false, true);
    unsafe = pipeline.channel().unsafe();
    setAdded();
}

上文分析了，unsafe 实际上就是 NioMessageUnsafe。分析 NioMessageUnsafe 的 bind 方法，实际上是 AbstractUnsafe 的方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
// io.netty.channel.AbstractChannel.AbstractUnsafe#bind
@Override
public final void bind(final SocketAddress localAddress, final ChannelPromise promise) {
    boolean wasActive = isActive();
    try {
        doBind(localAddress);
    } catch (Throwable t) {
        safeSetFailure(promise, t);
        closeIfClosed();
        return;
    }
    if (!wasActive && isActive()) {
        invokeLater(new OneTimeTask() {
            @Override
            public void run() {
                pipeline.fireChannelActive();
            }
        });
    }
    safeSetSuccess(promise);
}

核心代码为 doBind 方法，该方法是 NioServerSocketChannel 中的

1
2
3
4
@Override
protected void doBind(SocketAddress localAddress) throws Exception {
    javaChannel().socket().bind(localAddress, config.getBacklog());
}

javaChannel()方法返回的是NioServerSocketChannel实例初始化时所产生的Java NIO ServerSocketChannel实例（具体为ServerSocketChannelImple实例）。等价于语句serverSocketChannel.socket().bind(localAddress)完成了指定端口的绑定，然后开始监听此端口。绑定端口成功后，这里调用了我们自己定义的handler channelActive方法，绑定之前，isActive()方法返回false，绑定之后返回true。

main线程阻塞等待关闭

1
2
// Wait until the server socket is closed.
    f.channel().closeFuture().sync();

优雅关闭所有资源

1
2
3
4
5
} finally {
    // Shut down all event loops to terminate all threads.
    bossGroup.shutdownGracefully();
    workerGroup.shutdownGracefully();
}

4.3 - IO模型

基本概念

同步异步阻塞非阻塞

同步：当前线程接收返回结果

异步：另外一个线程接收返回结果，多个线程

阻塞：一直等待直到结果返回

非阻塞：干其它事，不用一直等

注意：没有异步阻塞这种

IO模型同步异步

通常会说到同步阻塞IO、同步非阻塞IO，异步IO几种术语，所谓阻塞就是发起读取数据请求的时，当数据还没准备就绪的时候，这时请求是即刻返回，还是在这里等待数据的就绪，如果需要等待的话就是阻塞，反之如果即刻返回就是非阻塞。

区分了阻塞和非阻塞后再来分别下同步和异步，在IO模型里面如果请求方从发起请求到数据最后完成的这一段过程中都需要自己参与，那么这种称为同步请求；反之，如果应用发送完指令后就不再参与过程了，只需要等待最终完成结果的通知，那么这就属于异步。

再看同步阻塞、同步非阻塞，他们不同的只是发起读取请求的时候一个请求阻塞，一个请求不阻塞，但是相同的是，他们都需要应用自己监控整个数据完成的过程。而为什么只有异步非阻塞而没有异步阻塞呢，因为异步模型下请求指定发送完后就即刻返回了，没有任何后续流程了，所以它注定不会阻塞，所以也就只会有异步非阻塞模型了。

5种IO模型

阻塞IO

非阻塞IO

多路复用IO

Java NIO就是多路复用IO

另外多路复用IO为何比非阻塞IO模型的效率高是因为在非阻塞IO中，不断地询问socket状态时通过用户线程去进行的，而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。

单线程可以配合Selector完成对多个Channel可读写事件的监控，这称之为多路复用

单线程+事件

多路复用仅针对网络IO、普通文件IO没法利用多路复用
如果不用Selector的非阻塞模式，线程大部分事件都在做无用功，而Selector能够保证
- 有可连接事件时才去连接
- 有可读事件才去读取
- 有可写事件才去写入
  - 限于网络传输能力，Channel未必时时可写，一旦Channel可写，会触发Selector的可写事件

信号驱动IO

异步IO

2种高性能设计模式

Reactor
Proactor

IO复用模型

Select

函数签名：

1
2
3
4
5
int select(int nfds,
            fd_set *restrict readfds,
            fd_set *restrict writefds,
            fd_set *restrict errorfds,
            struct timeval *restrict timeout);

传递给select函数的参数会告诉内核：

我们所关心的文件描述符（三类，读、写、异常）
对每个描述符，我们所关心的状态
我们要等待多长时间 fd_set是bitmap结构，默认长度为1024，由内核中一个常量定义，因此select最多处理的fd长度就是1024，要修改该长度，需要重新编译内核。 fd_set 的使用涉及以下几个 API：

1
2
3
4
5
 #include <sys/select.h>
int FD_ZERO(int fd, fd_set *fdset);  // 将 fd_set 所有位置 0
int FD_CLR(int fd, fd_set *fdset);   // 将 fd_set 某一位置 0
int FD_SET(int fd, fd_set *fd_set);  // 将 fd_set 某一位置 1
int FD_ISSET(int fd, fd_set *fdset); // 检测 fd_set 某一位是否为 1

从select函数返回后，内核告诉我们以下信息：

对我们的要求已经做好准备的描述符的个数
对于三种条件（读、写、异常），哪些描述符已经做好准备有了这些信息，我们可以调用合适的I/O函数，并且这些函数不会再阻塞。

select的缺点

fd_set中的bitmap是固定1024位的，也就是说最多只能监听1024个套接字。当然也可以改内核源码，不过代价比较大；
fd_set每次传入内核之后，都会被改写，导致不可重用，每次调用select都需要重新初始化fd_set；
每次调用select都需要拷贝新的fd_set到内核空间，这里会做一个用户态到内核态的切换；
拿到fd_set的结果后，应用进程需要遍历整个fd_set，才知道哪些文件描述符有数据可以处理。

Poll

poll 和 select 几乎没有区别。poll 采用链表的方式存储文件描述符，没有最大存储数量的限制。从性能开销上看，poll 和 select 的差别不大。

epoll

epoll 是对 select 和 poll 的改进，避免了“性能开销大”和“文件描述符数量少”两个缺点。即：

每次 select 需要把监控的 fds 传输到内核里，没有在内核中维护
socket 只唤醒 select，不能告诉它是哪个 socket 改进策略：
在内核里维护了 epoll 管理的 socket 集合，不用每次调用时都把所有管理的 fds 拷贝到内核
引入一个 ready_list 双向链表，callback 里面会把当前的 socket 加入到 ready_list 然后唤醒 epoll，被唤醒的 epoll 只需要遍历 ready_list 即可，这个链表里一定是有数据可读的 socket，相比于 select 就不会做无用的遍历简而言之，epoll 有以下几个特点：
使用红黑树存储文件描述符集合
使用队列存储就绪的文件描述符
每个文件描述符只需在添加时传入一次；通过事件更改文件描述符状态

select、poll 模型都只使用一个函数，而 epoll 模型使用三个函数：epoll_create、epoll_ctl 和 epoll_wait，我们分开介绍。

epoll_create

1
int epoll_create(int size);

epoll_create 会创建一个 epoll 实例，同时返回一个引用该实例的文件描述符。返回的文件描述符仅仅指向对应的 epoll 实例，并不表示真实的磁盘文件节点。其他 API 如 epoll_ctl、epoll_wait 会使用这个文件描述符来操作相应的 epoll 实例。当创建好 epoll 句柄后，它会占用一个 fd 值，在 linux 下查看 /proc/进程id/fd/，就能够看到这个 fd。所以在使用完 epoll 后，必须调用 close(epfd) 关闭对应的文件描述符，否则可能导致 fd 被耗尽。当指向同一个 epoll 实例的所有文件描述符都被关闭后，操作系统会销毁这个 epoll 实例。 epoll 实例内部存储：

监听列表：所有要监听的文件描述符，使用****红黑树
就绪列表：所有就绪的文件描述符，使用****链表

epoll_ctl

1
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll_ctl 会监听文件描述符 fd 上发生的 event 事件。参数说明：

epfd 即 epoll_create 返回的文件描述符，指向一个 epoll 实例
fd 表示要监听的目标文件描述符
event 表示要监听的事件（可读、可写、发送错误…）
op 表示要对 fd 执行的操作，有以下几种：
- EPOLL_CTL_ADD：为 fd 添加一个监听事件 event
- EPOLL_CTL_MOD：Change the event event associated with the target file descriptor fd（event 是一个结构体变量，这相当于变量 event 本身没变，但是更改了其内部字段的值）
- EPOLL_CTL_DEL：删除 fd 的所有监听事件，这种情况下 event 参数没用

返回值 0 或 -1，表示上述操作成功与否。 epoll_ctl 会将文件描述符 fd 添加到 epoll 实例的监听列表里，同时为 fd 设置一个回调函数，并监听事件 event。当 fd 上发生相应事件时，会调用回调函数，将 fd 添加到 epoll 实例的就绪队列上。

epoll_wait

1
2
int epoll_wait(int epfd, struct epoll_event *events,
               int maxevents, int timeout);

这是 epoll 模型的主要函数，功能相当于 select。参数说明：

epfd 即 epoll_create 返回的文件描述符，指向一个 epoll 实例
events 是一个数组，保存就绪状态的文件描述符，其空间由调用者负责申请
maxevents 指定 events 的大小
timeout 类似于 select 中的 timeout。如果没有文件描述符就绪，即就绪队列为空，则 epoll_wait 会阻塞 timeout 毫秒。如果 timeout 设为 -1，则 epoll_wait 会一直阻塞，直到有文件描述符就绪；如果 timeout 设为 0，则 epoll_wait 会立即返回

返回值表示 events 中存储的就绪描述符个数，最大不超过 maxevents。

epoll 的优点

一开始说，epoll 是对 select 和 poll 的改进，避免了“性能开销大”和“文件描述符数量少”两个缺点。对于“文件描述符数量少”，select 使用整型数组存储文件描述符集合，而 epoll 使用红黑树存储，数量较大。对于“性能开销大”，epoll_ctl 中为每个文件描述符指定了回调函数，并在就绪时将其加入到就绪列表，因此 epoll 不需要像 select 那样遍历检测每个文件描述符，只需要判断就绪列表是否为空即可。这样，在没有描述符就绪时，epoll 能更早地让出系统资源。

相当于时间复杂度从 O(n) 降为 O(1)

此外，每次调用 select 时都需要向内核拷贝所有要监听的描述符集合，而 epoll 对于每个描述符，只需要在 epoll_ctl 传递一次，之后 epoll_wait 不需要再次传递。这也大大提高了效率。

水平触发和边缘触发

水平触发（LT，Level Trigger）：当文件描述符就绪时，会触发通知，如果用户程序没有一次性把数据读/写完，下次还会发出可读/可写信号进行通知。

边缘触发（ET，Edge Trigger）：仅当描述符从未就绪变为就绪时，通知一次，之后不会再通知。

select 只支持水平触发，epoll 支持水平触发和边缘触发。

区别：边缘触发效率更高，减少了事件被重复触发的次数，函数不会返回大量用户程序可能不需要的文件描述符。

水平触发、边缘触发的名称来源：数字电路当中的电位水平，高低电平切换瞬间的触发动作叫边缘触发，而处于高电平的触发动作叫做水平触发。

举例：

如果一个客户端同时发来了 5 个数据包，正常的逻辑只需要唤醒一次 epoll ，把当前 socket 加一次到 ready_list 就行了，不需要加 5 次。然后用户程序可以把 socket 接收队列的所有数据包都读完。

但假设用户程序只读了一个包，然后处理报错了，后面不读了，那后面的 4 个包怎么处理？

如果是 ET 模式，就无法读取，因为没有把 socket 加入到 ready_list 的触发条件。除非该客户端发了新数据包过来，才会再把当前 socket 加入到 ready_list，在新包过来之前，这 4 个数据包都不会被读到。

而 LT 模式不一样，因为每次读完有感兴趣的事件发生之后，会把当前 socket 再加入到 ready_list，所以下次肯定能读到这个 socket，所以后面的 4 个数据包会被访问到，不论客户端是否发送新包。

Reference

美团技术团队-NIO

Java NIO：浅析I/O模型

字节 I/O 模型介绍

IO复用：IO处理杀手锏，带您深入了解select，poll，epoll

5 - Java

Introduction

Java知识体系及源码分析

5.1 - 基础

Introduction

Java基础

5.1.1 - 双亲委派机制

背景知识

JDK 中默认类加载器有 3 个：

BootStrapClassLoader
ExtClassLoader
AppClassLoader 上述3个前者是后者的父加载器。

定义

双亲委派机制：加载器在加载过程中，先把类交由父类加载器进行加载，父类加载器没找到才优自身加载。

目的

防止内存中存在多份同样的字节码，安全考虑。

类加载规则

如果一个类由类加载器X加载，那么类的依赖类也是由相同的类加载器加载。

打破双亲委派机制

加载类时不是按照从 APPClassLoader -> ExtClassLoader -> BootStrap ClassLoader 的顺序找，就是打破双亲委派机制。

只要不依次往上交由父加载器进行加载，就是打破双亲委派机制。

因为加载class核心方法是 LoaderClass 类的 loadClass 方法（双亲委派机制的核心实现）。所以只要自定义 ClassLoader，重写 loadClass 方法（不依照往上开始寻找类加载器），就是打破双亲委派机制。

案例分析

Tomcat

目的

隔离不同的应用程序，防止类全限名相同导致冲突。

类加载结构图

Web应用层级隔离

Tomcat 给每个 Web 应用创建一个类加载器实例（WebAppClassLoader），该加载器重写了 loadClass 方法，优先加载当前应用目录下的类，如果找不到才一层一层往上找。这样就实现了 Web 应用层级的隔离。

应用程序间共享

当然，并不是 Web 应用程序下的所有依赖都需要隔离，如 Redis 等类可以在应用程序中共享（如果需要），版本相同时没必要每个 Web 应用程序都独自加载一份。

实现方式是在 WebAppClassLoader 上加了一个父类加载器（SharedClassLoader），如果 WebAppClassLoader 自身没有加载到某个类，就委托 SharedClassLoader 去加载。

其实就是把需要应用程序之间需要共享的类放到一个共享目录下。

隔离Tomcat类

为了隔离 Web 应用和 Tomcat 自身的类，又有类加载器（CatalinaClassLoader）来加载 Tomcat 本身的依赖。

Tomcat与应用程序共享

如果 Tomcat 本身的依赖和 Web 应用还需要共享，还有类加载器（CommonClassLoader）来加载进而实现共享。

小结

各个类加载器的加载目录可以查看 tomcat 的 catalina.properties 配置文件。

JDBC

目的

JDBC定义了接口，具体实现类由各个厂商来实现（如MySQL等）。

实现

使用 JDBC 时是使用 DriverManager 来获取 Connection，DriverManager 在 java.sql 包中，按理是由 BootStrapClassLoader 来加载，但其无法加载第三方库中的类。当使用 DriverManager.getConnection 时无法加载到各个厂商实现的类。

所以 DriverManager 的解决方案是在其初始化时，得到“线程上下文加载器”，获取 Connection 时，先找 ExtClassLoader 和 BootStrapClassLoader（肯定加载不到），最终由 AppClassLoader 进行加载。

讨论

本来是由 BootStrapClassLoader 进行类加载，但是 JDBC 改成了“线程上下文加载器”加载，但还遵守了：依次往上找父类加载器进行加载，都找不到时才由自身加载。类加载规则没有变化（也有说破坏了，仁者见仁智者见智，了解原理即可）。

5.2 - JVM

Introduction

JVM

5.2.1 - 垃圾回收算法

概述

当进行系统调优与线上问题排查时，深入理解 Java 虚拟机垃圾回收机制的底层原理是非常有必要的。Java 垃圾回收器的种类繁多，其设计主要在吞吐量（内存空间）与实时性（用户线程中断）进行权衡，适应场景也有所区别。本文主要针对 JDK8 进行分析。

内存/堆结构

新生代和老年代默认分配空间比为 1:2。

新生代又可以分为：

Eden 区
两个 Survial 区（S0/S1）空间占比：Eden（8/10）、S0（1/10）、S1（1/10）

一块独立的内存区域只能使用一种垃圾回收算法，根据对象生命周期特征，将其划到不同区域，再对特定区域使用特定的垃圾回收算法，将垃圾回收算法的优点发挥到极致。这种组合的垃圾回收算法成为分代垃圾回收算法。如：新生代使用标记复制算法，老年代使用标记整理算法。

对象回收算法

判断对象回收一般有两种方法。

引用计数器算法

对象被引用一次计数器加 1，对象取消被引用计数器减 1，计数器为 0 时则表示对象不被引用，可以被销毁。

该算法简单高效。但对于循环引用或者其它复杂情况，需要更多的开销，所以一般不使用该方法。

可达性分析算法

顺着 GCRoot 根向下搜索，只要在引用链上的对象就是可达的，在这之外的对象则不可达，不可达的对象就是可回收的。GCRoots 对象一般包括：

虚拟机栈帧上本地变量表中的引用对象（方法参数、局部变量、临时变量）
方法区中的静态属性引用类型对象、常量引用对象
本地方法栈中的引用对象（Native方法的引用对象）
Java虚拟机内部的引用对象，如异常对象、系统类加载器等
被同步锁（synchronize）持有的对象
Java 虚拟机内部情况的注册回调、本地缓存等

垃圾回收算法

垃圾具体如何回收涉及到垃圾回收算法。垃圾回收算法可分为3种：

标记清除算法
标记复制算法
标记整理算法

标记清除算法

流程

标记出所有需要被回收的对象
对标记对象进行统一清除

优点

效率高

缺点

执行效率不可控（如大部分对象都可回收，收集器需要一一大量执行标记、收集操作）
产生大量内存碎片

标记复制算法

流程

标记复制算法将内存分为大小相同的两个区域：

运行区域
预留区域所有创建的新对象都分配到运行区域，当该区域内存不足时，则将该区域全部存活对象复制到预留区域，然后再清空整个运行区域内存。此时这两个区域的角色也互相调换。

标记复制算法在存在大量垃圾对象时，只需要复制较少的存活对象，不会产生内存碎片，新内存的分配只需要移动堆顶指针顺序分配即可，很好地兼顾了效率与内存碎片的问题。

优点

兼顾效率
避免内存碎片

缺点

预留一半空间造成浪费
少量垃圾大量存活对象时效果很差，复制操作很多但回收空间少

标记整理算法

基于前两种算法的优缺点，又提出了标记整理算法。

标记阶段：和其他算法一样
整理阶段：将存活的对象向内存空间一端移动，然后将存活对象边界以外的空间全部清空

堆内存回收过程

第一次MinorGC

Eden 区空间不足时，触发 MinorGC
垃圾回收器首先将 Eden 区中存活对象复制到 S0 区中（S0或S1，互备）
清空 Eden 区空间

第二次MinorGC

Eden 区空间不足时，再次触发 MinorGC
将 Eden 区存活对象复制到 S1 区
清空 Eden 区空间
将 S0 区存活对象复制到 S1 区并将对象的年龄加 1
清空 S0 区第三次及之后 MinorGC 同理。

这里为了减少复制算法空白区域的空间浪费，不是将内存一分为二，而是巧妙地将内存分为三个区域，预留的空白区域只占整个年轻代的空间的 1/10。

进入老年代

进入老年代空间的条件：

从年轻代晋升
- 年轻代分配担保：Survivor 区只有年轻代空间的 2/10 且一分为二，空间不足以分配所有存活对象时，将无法容纳的对象分配到老年代中
- 对象年龄超过虚拟机 MaxTenuringThreshold 参数大小的对象（Parallel Scavenge:å 15，CMS: 6, G1: 15）
- Survivor 空间中相同年龄所有对象大小的总和大于Survivor空间的一半（TargetSurvivorRatio），大于或等于该年龄的对象直接进入老年代
直接分配
- 超过虚拟机 PretenureSizeThreshold 参数大小的大对象
- 超过 Eden 大小的对象
- 新生代分配失败，如大字符串或者大数组

FullGC

老年代空间不足时就会触发 FullGC，FullGC 触发的条件一般有：

调用 System.gc()（建议虚拟机执行 FullGC，不一定真正去执行）
老年代空间不足
空间分配担保失败
JDK 1.7 及以前的永久代空间不足
CMS GC 时出现 Concurrent Mode Failure

5.2.2 - JVM调优

优化系统思路

首先排查 DB 的问题如评估索引是否合理，是否需要引入分布式缓存、是否需要分库分表等
扩容横向和纵向扩容，解决系统压力过大导致的硬件能力不足出现的问题
代码优化检查代码上是否存在资源浪费的情况，或者逻辑上有优化的空间，比如通过并行的方式处理请求等等）
JVM排查并优化观察是否存在多次GC问题或者GC时间过长等等
网络和操作系统层面优化查看内存/CPU/网络/硬盘读写指标是否正常等

JVM调优

参考指标

吞吐量
停顿时间
垃圾回收频率

调优方法

内存分配策略

内存区域大小以及相关策略（比如整块堆内存占多少、年轻代占多少、老年代占多少、Survivor占多少、晋升老年代的条件等等）

比如 -Xmx：设置堆的最大值、-Xms：设置堆的初始值、-Xmn：表示年轻代的大小、-XX:SurvivorRatio：伊甸区和幸存区的比例等等

按经验来说：IO密集型的可以稍微把「年轻代」空间加大些，因为大多数对象都是在年轻代就会灭亡。内存计算密集型的可以稍微把「老年代」空间加大些，对象存活时间会更长些

垃圾回收器

选择合适的垃圾回收器，以及各个垃圾回收器的各种调优参数

比如（-XX:+UseG1GC：指定 JVM 使用的垃圾回收器为 G1、-XX:MaxGCPauseMillis：设置目标停顿时间、-XX:InitiatingHeapOccupancyPercent：当整个堆内存使用达到一定比例，全局并发标记阶段就会被启动等等）

调优步骤

监控GC状态
生成dump文件
分析dump文件
调整GC类型/内存分配

调优参数参考

堆大小

参数-Xms -Xmx标志限定堆的最小、最大值。为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，通常把最大、最小设置为相同的值。

堆内存分配比例

年轻代和老年代默认比例是 1:2 分配堆内存，可以通过调整二者之间的比例 NewRadio 来调整二者之间的大小。

年轻代通过 -XX:newSize -XX:MaxNewSize 来设置其绝对大小。同样为了防止堆收缩，通常将二者设置成同样大小。

年轻代/老年代大小

更大的年轻代必然导致更小的老年代：大的年轻代会延长普通GC的周期，且增加每次 YGC 的时间。小的老年代导致更频繁的 FullGC。
更小的年轻代必然导致更大的老年代：小的年轻代会导致 YGC 很频繁，但每次 GC 时间会很短。大的老年代会减少 FullGC 的频率。如何选择应该依赖应用程序的对象生命周期分布情况：
如果应用存在大量的临时对象，应该选择更大的年轻代
如果应用存在相对较多的持久对象，老年代应该适当增大但是很多应用都没有这样明显的特征。所以抉择时应该根据以下几点：

本着 FullGC 尽量少的原则，让老年代尽量缓存常用对象（默认比例1:2也是基于这个原则）
观察一段时间，查看峰值时老年代占用内存大小，在不影响 FullGC 的前提下，适当加大年轻代，比如将比例控制成 1:1。但应该给老年代至少预留三分之一的增长空间。

垃圾回收算法

在配置较好的机器上（如多核、大内存），可以为老年代选择并行回收算法：-XX:+UseParallelOldGC。

线程堆栈大小

每个线程默认开启 1M 的堆栈，用于存放栈帧、调用参数、局部变量等。可以根据实际情况调小，理论上总内存大小不变的情况下，这样可以开启更多的线程。当然也受限于操作系统。

调优策略

FullGC

FullGC 会对整个堆进行整理，包括年轻代、老年代、永久代，所以会比较慢，因此应该尽可能减少 FullGC 的次数。

可能的原因：

老年代被写满
永久代空间不足
System.gc() 被显示调用

工具

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。

jconsole

JMX的可视化管理工具。

用于对 JVM 中的内存、线程和类等进行监控；

jvisualvm

JDK 自带的全能分析工具。

可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

jps

虚拟机进程状况工具。

用来输出JVM中运行的进程状态「基础」信息（进程号、主类）。这个命令很常用的就是用来看当前服务器有多少Java进程在运行，它们的进程号和加载主类是什么。

jstat

虚拟机统计信息监控工具。

监视虚拟机各种运行状态信息，可以显示本地或者是远程虚拟机进程中「统计类」信息，如类装载、编译相关信息统计、各个内存区域GC概况和统计、垃圾收集、JIT编译等运行数据。这个命令很常用于看GC的情况。

jinfo

通过jinfo命令来查看和调整Java进程的「运行参数」。

jmap

通过jmap命令来查看Java进程的「内存信息」。可以生成虚拟机的内存转储快照（heapdump文件）。常用于将JVM内存信息dump到文件，然后用MAT( Memory Analyzer tool 内存解析工具)对文件进行分析。

jstack

堆栈跟踪工具。

查看JVM「线程信息」，用于生成虚拟机当前时刻的线程快照。这个命令用常用语排查死锁相关的问题。

jhat

分析内存转储快照，不推荐使用，而且慢

Arthas

还有近期比较热门的Arthas（阿里开源的诊断工具），涵盖了上面很多命令的功能且自带图形化界面。这也是常用的排查和分析工具。

JIT优化技术

JIT优化技术比较出名的有两种：方法内联和逃逸分析。

方法内联

把「目标方法」的代码复制到「调用的方法」中，避免发生真实的方法调用。

因为每次方法调用都会生成栈帧（压栈出栈记录方法调用位置等等）会带来一定的性能损耗，所以「方法内联」的优化可以提高一定的性能。

在JVM中也有相关的参数来指定（-XX:MaxFreqInlineSize、-XX:MaxInlineSize）。

逃逸分析

判断一个对象是否被外部方法引用或外部线程访问的分析技术，如果「没有被引用」，就可以对其进行优化，如：

锁消除（同步忽略）该对象只在方法内部被访问，不会被别的地方引用，那么就一定是线程安全的，可以把锁相关的代码给忽略掉
栈上分配该对象只会在方法内部被访问，直接将对象分配在「栈」中

Java默认是将对象分配在「堆」中，是需要通过JVM垃圾回收期进行回收，需要损耗一定的性能，而栈内分配则快很多

标量替换/分离对象当程序真正执行的时候可以不创建这个对象，而直接创建它的成员变量来代替。将对象拆分后，可以分配对象的成员变量在栈或寄存器上，原本的对象就无需分配内存空间了。

调优案例

内存分配大小

现象：

部分机器出现异常：GC overhead limit exceeded

该异常代表GC为了释放很小的空间却耗费了太多的时间，原因一般有两个：

堆太小
有死循环或大对象因为是部分机器，所以排查原因2，怀疑是部分机器中堆设置太小，通过 ps -ef | grep java 查看内存分配大小（如堆-Xms -Xmx），如果太小而该应用又比较吃内存，适当调大堆中各区域大小。

内存分配比例

现象：

系统经常出现卡顿

查看GC情况：

1
2
3
$ jstat -gcutil
S0 S1 E O P YGC YGCT FGC FGCT GCT
13.01 0.00 5.19 62.67 20.76 56 2.032 6 7.012 9.026

可以看到不同GC耗时和次数，Young GC 执行了 56 次，耗时 2.032 秒，平均耗时 36 ms 在正常范围内。FullGC 执行了 6 次，耗时 7.012 秒，平均耗时超过1秒。可以判断是 FullGC 耗时较长导致的。进一步查询年轻代和老年代的大小比例 NewRatio=9，可以得出原因：

年轻代太小，导致对象提前进入老年代，触发老年代发生 FullGC
老年代太大，进行 FullGC 耗时较大优化方法：调整 NewRatio 大小。

这样就是把对象控制在年轻代就清理掉，防止进入老年代。

对象未释放

现象：

性能测试过程中，发现内存占用率高，Full GC 频繁。

使用 sudo -u admin -H jmap -dump:format=b,file=FileName.hprof pid 来 dump 内存生成 dump 文件，并使用 MAT 进行分析。

可能得问题：内存泄漏

1、某数据结构（列表、队列等）引用的大量对象未被释放，导致整个线程占用内存过高（几百兆）。优化相关代码即可。

2、匿名对象引用的对象未被释放

元数据空间太小

查看GC log，发现 FullGC 时，老年代占据的内存比例很小（如低于60%）却发生了 FullGC，metaspace 占用的空间远大于默认的分配值。

Reference

美团：Java中9种常见的CMS GC问题分析与解决

优化 FullGC

JVM性能调优6大步骤

5.3 - 并发

Introduction

Java并发

5.3.1 - Java并发编程的艺术

Java内存模型

Java内存模型的基础

Java线程之间的通信由Java内存模型（JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

重排序类型

3种指令重排序

编译器优化的重排序
指令级并行的重排序
内存系统的重排序第1种属于编译器重排序，第2、3种属于处理器重排序。

对于编译器重排序：JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。

对于处理器重排序，JMM的处理器重排序规则会要求Java编译器生成指令序列时，插入特定类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

为了保证内存可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为4类。

其中StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他3个屏障的效果。但该屏障开销较大，要把写缓冲区中的数据全部刷新到内存中（Buffer Fully Flush）。

happens-before简介

密切相关的happens-before规则如下：

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
传递性：如果A happens-before B，且 B happens-before C，那么A happens-before C。

happens-before的定义很微妙，两个操作之间具有happens-before，并不意味着前一个操作必须要在后一个操作之前执行！！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）

重排序

数据依赖性

两个操作访问同一个变量，且两个操作中有一个为写操作，此时这两个操作之间存在数据依赖性。数据依赖分为3种：写后读、写后写、读后写。

这里的数据依赖性仅对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial语义

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

不会对存在数据依赖关系的操作做重排序，但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

程序顺序规则

即代码顺序。但JMM允许对结果无影响的重排序。

重排序对多线程的影响

顺序一致性

顺序一致性内存模型

理想化的概念

两大特性：

1、一个线程中的所有操作必须按照程序的顺序来执行

2、（不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。

在任意时间点最多只能有一个线程可以连接到内存（串行化）

但是，在JMM中没有这个保证。

同步程序的顺序一致性效果

**顺序一致性模型中，所有操作完全按程序的顺序串行执行。而在JMM中，临界区内的代码可以重排序（但JMM不允许临界区内的代码“逸出”到临界区之外，那样会破坏监视器的语义）。**JMM会在退出临界区和进入临界区这两个关键时间点做一些特殊处理，使得线程在这两个时间点具有与顺序一致性模型相同的内存视图。

由于监视器互斥执行的特性线程之间无法“观察”到对方在临界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。

未同步程序的执行特性

要么之前写入的值，要么默认值，不会无中生有。

未同步程序在两个模型中的差异：

1、顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行

2、顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有的线程能看到一致的操作执行顺序。

3、JMM不保证对64位long型和double型变量的写操作具有原子性，而顺序一致性模型保证对所有的内存读/写都具有原子性。（总线的工作机制密切相关，32位处理器）

注意：在JSR-133之前的旧内存模型中，64位long/double型变量的读/写操作均可被才分为两个32位的读/写操作。从JSR-133内存模型开始（JDK5），仅仅只允许把64位long/double型变量的写操作拆分为两个32位的写操作来执行，但任意的读操作必须具有原子性（即任意读操作必须要在单个读事务中执行）。

volatile的内存语义

volatile变量自身具有下列特性：

可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性 volatile读的内存语义：

当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从内存中读取共享变量。

volatile写和volatile读的内存语义总结：

线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了（其对共享变量所做修改的）消息
线程B读一个volatile变量，实质上是线程B接受了之前某个线程发出的（在写这个volatile变量之前对共享变量所做修改的）消息
线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息 volatile重排序规则：

1、第2个操作是volatile写时，无论第1个操作是什么，都不能重排序

2、第1个操作是volatile读时，无论第2个操作是什么，都不能重排序

3、第1个操作是volatile写，第二个操作是volatile读时，不能重排序

基于保守策略的JMM内存屏障插入策略（可以保证任意处理平台，任意程序中都能得到正确的volatile内存语义）

在每个volatile写操作的前面插入一个StoreStore屏障
在每个volatile写操作的后面插入一个StoreLoad屏障
在每个volatile读操作的后面插入一个LoadLoad屏障
在每个volatile读操作的后面插入一个LoadStore屏障

注意：第2条，也可以是每个volatile读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑，JMM最终选择了在每个volatile写操作的后面插入一个StoreLoad屏障

第3、4条策略非常保守，但在实际执行中，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障

JSR-133为什么要增强volatile的内存语义

增强：新的java内存模型中不允许volatile变量与普通变量重排序

确保volatile的写-读和锁的释放-获取具有相同的内存语义

（个人理解）提醒：普通读、写可能用的是volatile的赋值，所以需要增加内存屏障隔离。

锁的内存语义

实际上和volatile差不多，也是将本地内存置为无效，刷新主内存等等。

锁释放和锁获取的内存语义总结：

线程A释放一个锁，是指上市线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息
线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息
线程A释放锁，随后线程B获取这个锁，这个过程实际上是线程A通过主内存向线程B发送消息。

锁内存语义的实现

final域的内存语义

final域的重排序规则

对于final域，编译器和处理器要遵守两个重排序规则

1、在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序

2、初次读一个final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序

写final域的重排序规则

1、JMM禁止编译器把final域的写重排序到构造函数之外

2、编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外

写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保障。

读final域的重排序规则

在一个线程中，初次读该对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读final域操作的前面插入一个LoadLoad屏障（间接依赖关系）。

JSR-133为什么增强final的语义

防止读到final默认值

保证只要对象是正确构造的（被构造对象引用在构造函数中没有“逸出”），不需要使用同步（lock和volatile的使用）就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。

happens-before

happens-before规则

1、程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作

2、监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁

3、volatile变量规则：对一个volatile域的写，happens-before于随后对这个锁的加锁

4、传递性：略

5、start()规则：如果线程A执行操作ThreadB.start()，那么A线程的ThreadB.start()操作happen-before于线程B中的任意操作

6、join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回

双重检查锁定与延迟初始化

双重检查锁定看起来似乎很完美，但这是一个错误的优化！在线程执行到第一个判空读取到instance不为null时，instance引用的对象有可能还没有完成初始化。

解释：即线程A初始化化instance时，线程B可能访问到一个未完成初始化的instance，从而造成错误。加锁只能保证线程B不进入锁住的代码，即不再次初始化instance，但不能限制线程B获取instance。

问题根源：

instance=new Singleton()这行代码可以分解为如下3行伪代码：

1
2
3
memory = allocate(); // 1：分配对象的内存空间
ctorInstance(memory); // 2：初始化对象
instance = memory;  // 3：设置instance指向刚分配的内存地址

这3行伪代码中的2和3之间，可能会被重排序（在一些JIT编译器上）。解决方案：

1、禁止第2和第3行伪代码重排序：volatile修饰instance

优势：volatile除了可以对静态字段实现延迟初始化外，还可以对实例字段实现延迟初始化。

2、允许第2和第3行伪代码重排序，但不允许其他线程“看到”这个重排序：内部类

JVM在类初始化期间会获取这个初始化锁，并且每个线程至少获取一次锁来确保这个类已经被初始化过

Java立即初始化类场景

根据Java语言规范，在首次发生下列任意一种情况时，一个类或接口类型T将被立即初始化：

1）T是一个类，而且一个T类型的实例被创建

2）T是一个类，且T中声明的一个静态方法被调用

3）T中声明的一个静态字段被赋值

4）T中声明的一个静态字段被使用，而且这个字段不是一个常量字段

5）T是一个顶级类（Top Level Class），而且一个断言语句嵌套在T内部被执行

Java并发编程基础

线程简介

线程优先级

整形成员变量priority来控制优先级，范围从1-10，可通过setPriority(int)来修改优先级，默认为5，优先级高的线程分配时间片的数量要多余优先级低的线程。设置线程优先级时，针对频繁阻塞（休眠或I/O操作）的线程需要设置较高优先级，而偏重计算（需要较多CPU时间或者偏运算）的线程则设置较低的优先级，确保处理器不会被独占。

线程优先级不能作为程序正确性的依赖，因为操作系统可以完全不用理会Java线程对于优先级的设定。

Daemon线程

支持型线程，主要被用作程序中后台调度以及支持性工作。可以通过调用Thread.setDaemon(true)将线程设置为Daemon线程。

Daemon属性需要在启动线程之前设置，不能再启动线程之后设置。

Daemon线程被用作完成支持性工作，但是在Java虚拟机退出时Daemon线程中的finally块并不一定会执行。

在构建Daemon线程时，不能依靠finally块中的内容来确保执行关闭或清理资源的逻辑。

理解中断

从Java的API中可以看到，许多声明抛出InterruptedException的方法（例如Thread.sleep(long millis)方法）这些方法在抛出InterruptException之前，Java虚拟机会先将该线程的中断标志位清除，然后抛出InterruptedException，此时调用isInterrupted()方法将会返回false。

过期的suspend()、resume()、stop()

suspend()、resume()、stop()方法完成了线程的暂停、回复和终止工作。但是这些API是过期的，不建议使用。

不建议使用原因主要有：以suspend()方法为例，再调用后线程不会释放已经占有的资源（比如锁），而是占有着资源进入睡眠状态，容易引发死锁问题。同样，stop()方法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资源工作的机会，因此可能会导致程序可能工作在不确定状态下。

暂停和恢复操作可以使用等待/通知机制来替代

安全地终止线程

中断最适合用来取消或停止任务。或者利用一个boolean变量（自定义）来控制是否需要停止任务并终结该线程。

线程间通信

volatile和synchronized关键字

等待/通知机制

使用共享变量+sleep()（休眠用来防止过快的“无效”尝试）看似能够实现所需功能，但存在如下问题：

1、难以确保及时性：休眠时长

2、难以降低开销：降低时长消耗更多处理器资源

Java通过内置的等待/通知机制能够很好的解决以上问题

等待/通知的相关方法是任意Java对象都具备的，定义在Object类上。

notify()：通知一个在对象上等待的线程，使其从wait()方法返回，而返回的前提是该线程获取到了对象的锁。

调用wait()、notify()以及notifyall()时需要注意的细节：

1、使用wait()、notify()、notifyAll()时需要先对调用对象加锁

2、调用wait()方法后，线程状态由RUNNING变为WAITING，并将当前线程放置到对象的等待队列。

3、notify()或notifyAll()方法调用后，等待线程依旧不会从wait()返回，需要notify()或者notifyAll()的线程释放锁之后，等待线程才有机会从wait()返回。

4、notify()方法将等待队列中的一个等待线程从等待队列中移到同步队列中，而notifyAll()方法则是将等待队列中所有的线程全部移到同步队列中，被移动的线程状态由WAITING变为BLOCKED。

5、从wait()方法返回的前提是获取调用对象的锁。

等待/通知的经典范式

等待方遵循如下原则：

1、获取对象的锁

2、如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。

3、条件满足则执行对应的逻辑

1
2
3
4
5
6
synchronized(对象) {
  while(条件不满足) {
    对象.wait();
  }
  // 对应的处理逻辑
}

通知方遵循如下原则： 1、获得对象的锁

2、改变条件

3、通知所有等待在对象上的线程

1
2
3
4
synchronized(对象) {
  // 改变条件
  对象.notifyAll();
}

管道输入/输出流

管道输入/输出流和普通的文件输入/输出流或者网络输入/输出流不同之处在于，它主要用于线程之间的数据传输，而传输的媒介为内存。

管道输入/输出流主要包括了如下4种具体实现：PipedOutputStream、PipedInputStream、PipedReader和PipedWriter，前两种面向字节，而后两种面向字符。

Thread.join()的使用

线程A调用了thread.join()语句的含义：当前线程A等待thread线程终止之后才从thread.join()返回。还有join(long millis)和join(long millis, int nanos)两个具备超时特性的方法。

join源码与上述总结的等待/通知经典范式一致，即加锁、循坏和处理逻辑3个步骤。

ThreadLocal的使用

线程应用实例

等待超时模式

数据库连接池示例

Java中的锁

Lock接口

Lock接口提供的synchronized关键字不具备的主要特性

1、尝试非阻塞地获取锁（tryLock）

当前线程尝试获取锁，如果这一时刻锁没有被其他线程获取锁，则成功获取并持有锁

2、能被中断地获取锁（lockInterruptibly）

与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程能被中断异常将会被抛出，同时锁会被释放

3、超时获取锁

队列同步器

队列同步器的接口与实例

同步器可重写的方法

1、tryAcquire

2、tryRelease

3、tryAcquireShared

4、tryReleaseShared

5、isHeldExclusively：当前同步器是否在独占模式下被线程占用，一般该方法表示是否被当前线程所独占

同步器提供的模板方法

1、acquire

2、acquireInterruptibly：响应中断

3、tryAcquireNanos：在acquireInterruptibly基础上增加了超时限制，获取到返回true

4、acquireShared

5、acquireSharedInterruptibly

6、tryAcquireSharedNanos

7、release

8、releaseShared

9、getQueuedThreads：获取等待在同步队列中的线程集合

同步器提供的模板方法基本分为3类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况。

队列同步器的实现分析

主要包括：同步队列、独占式同步状态获取与释放、共享式同步状态获取与释放以及超时获取同步状态等同步器的核心数据结构与模板方法。

1、同步队列

2、独占式同步状态获取与释放

acquire，该方法对中断不敏感

3、重入锁

公平锁多一个hasQueuedPredecessors()方法判断，即加入了同步队列中当前节点是否有前驱节点的判断。

非公平锁的上下文切换次数比公平锁低，效率更高。

读写锁

ReadWriteLock仅定义了获取读锁和写锁的两个方法，即readLock()和writeLock()方法。而其实现——ReentrantReadWriteLock，除了接口方法之外，还提供了一些便于外界监控其内部工作状态的方法，如下：

1、getReadLockCount：返回读锁被获取的次数。该次数不等于获取读锁的线程数（可重入。

2、getReadHoldCount：返回当前线程获取读锁的次数。该方法在Java6中加入到ReentrantReadWriteLock中，使用ThreadLocal保存当前线程获取的次数

3、isWriteLocked：判断写锁是否被获取

4、getWriteHoldCount：返回当前写锁被获取的次数

读写状态的设计

读写锁的自定义同步器需要在同步状态（一个整型变量）上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。

如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量。读写锁将变量切分成了两个部分，高16位表示读，低16位表示写。

状态划分的推论：S不等于0时，当写状态（S&0x0000FFFF）等于0时，则读状态（S>>>16）(无符号补0右移16位)大于0，即读锁已被获取

写锁的获取与释放

写锁是一个支持重进入的排它锁。

读锁的获取与释放

锁降级

锁降级是指写锁降级成为读锁。如果当前线程用油写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。

锁降级中读锁的获取是否必要？

必要的。保证数据的可见性，如果不获取读锁而是直接释放写锁，假设另一线程T修改了数据，那么当前线程无法感知线程T的数据更新

RentrantReadWriteLock不支持锁升级。

LockSupport工具

Condition接口

Object的监视器方法和Condition接口对比：

对比项	Object Monitor Methods	Condition
前置条件	获取对象的锁	调用Lock.lock()获取锁调用Lock.newCondition()获取Condition对象
调用方式	直接调用如：object.wait()	直接调用如：condition.await()
等待队列个数	一个	多个
当前线程释放锁并进入等待状态	支持	支持
当前线程释放锁并进入等待状态，在等待状态中不响应中断	不支持	支持
当前线程释放锁并进入超时等待状态	支持	支持
当前线程释放锁并进入等待状态到将来的某个时间	不支持	支持
唤醒等待队列的一个线程	支持	支持
唤醒等待队列的全部线程	支持	支持

Condition接口与示例

Condition对象是有Lock对象（调用Lock对象的newCondition()方法）创建出来的。Condition依赖Lock对象。

Condition的实现分析

主要包括：等待队列、等待和通知。

在Object的监视器模型上，一个对象拥有一个同步队列和等待队列。而并发包中的Lock（更确切地说是同步器）拥有一个同步队列和多个等待队列。

等待

调用Condition的await()方法（或以await开头的方法），会使当前线程进入等待队列并释放锁，同时线程状态变为等待状态。

如果从队列（同步队列和等待队列）的角度看await()方法，当调用await()方法时，相当于同步队列的首节点（获取了锁的节点）移动到了Condition的等待队列中。

**当等待队列中的节点被唤醒，则唤醒节点的线程开始尝试获取同步状态。**如果不是通过其他线程调用Condition.signal()方法唤醒，而是对等待线程进行中断，则会抛出InterruptedException。

通知

调用Condition的signal()方法，将会唤醒在等待队列中等待时间最长的节点（首节点），在唤醒节点之前，会将节点移到同步队列中，然后加入到获取同步状态的竞争中。

Condition的signalAll()方法，相当于对等待队列中的每个节点均执行一次signal()方法，效果就是将等待队列中所有节点全部移动到同步队列中，并唤醒每个节点的线程。

Java并发容器和框架

ConcurrentHashMap

ConcurrentLinkedQueue

Java中的阻塞队列

Fork/Join框架

工作窃取算法

双端队列

Java中的13个原子操作类

原子更新基本类型类

AtomicBoolean
AtomicInteger
AtomicLong

原子更新数组

AtomicIntegerArray
AtomicLongArray
AtomicReferenceArray
AtomicIntegerArray

原子更新引用

AtomicReference
AtomicReferenceFieldUpdater
AtomicMarkableReference

原子更新字段类

AtomicIntegerFieldUpdater
AtomicLongFieldUpdater
AtomicStamedReference

Java中的并发工具类

等待多线程完成的CountDownLatch

同步屏障CyclicBarrier

控制并发线程数的Semaphore

线程间交换数据的Exchanger

Java中的线程池

Executor框架

Java并发编程实战

5.4 - Web

Introduction

Java web相关，如JSP、tomcat等

5.5 - 框架

Introduction

Java框架

5.5.1 - Mybatis

Introduction

Mybatis

5.5.2 - Spring

Introduction

Spring

5.5.2.1 - 01.Spring基础知识

基础

什么是 Spring Boot Starters

解决引用依赖配置繁琐的问题。

Spring Boot坚信“约定大于配置”理念。

使用ConfigurationProperties和AutoConfiguration配置。starter的ConfigurationProperties还使得所有的配置属性被聚集到一个文件中（一般在resources目录下的application.properties）

Spring Boot 支持哪些内嵌 Servlet 容器

tomcat
jetty
undertow

如何在spring容器中使用Jetty而不是Tomcat

在pom.xml中排除tomcat引入jetty即可

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-starter-web</artifactId>  
    <!-- 使用Jetty，需要在spring-boot-starter-web排除spring-boot-starter-tomcat，因为SpringBoot默认使用tomcat --> 
    <exclusions>  
        <exclusion>  
            <groupId>org.springframework.boot</groupId>  
            <artifactId>spring-boot-starter-tomcat</artifactId>  
        </exclusion>  
    </exclusions>  
</dependency>  

<!-- Jetty适合长连接应用，就是聊天类的长连接 -->  
<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-starter-jetty</artifactId>  
</dependency> 

介绍一下@SpringBootApplication注解

见注解专题

SpringBoot的自动装配是如何实现的

见自动装配专题

开发RESTful web常用的注解有哪些

@GetMapping
@PostMapping
@RequestMapping
@ResponseBody

springboot常用的两种配置文件

properties
yaml

常见的Bean映射工具

BeanUtils
BeanCopier
Dozer
Orika

Ref：https://www.cnblogs.com/songhaibin/p/13382799.html

springboot如何监控系统运行状况

Spring boot Actuator提供了一组基于HTTP和JMX内置的EndPoints用于在系统运行时监控系统的运行情况。详情可以参见Spring boot官网在此列举一些常用的内置EndPoints

springboot如何做请求参数校验

Bean Validation

1
2
3
4
<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-validation</artifactId>
</dependency>

springboot的验证框架提供了一系列的注解用于验证参数，完整的注解可以去javax.validation.constraints这个包下看。这里整理一下：

注解	说明
@AssertFalse	被注释的元素必须为 false
@AssertTrue	被注释的元素必须为 true
@DecimalMax(value)	被注释的元素必须是一个数字，其值必须小于等于指定的最大值

Ref: 如何使用springboot优雅地校验请求参数

如何使用springboot实现全局异常处理

SpringBoot中有一个ControllerAdvice的注解，使用该注解表示开启了全局异常的捕获，我们只需在自定义一个方法使用ExceptionHandler注解然后定义捕获异常的类型即可对这些捕获的异常进行统一的处理。

Ref: SpringBoot全局异常准备

springboot中如何实现定时任务

自带的定时任务处理器 @Scheduled 注解
第三方框架 Quartz Ref: Spring Boot 中实现定时任务的两种方式

ClassXmlAplicationContext和FileSystemXmlApplicationContext的区别

Ref：https://www.cnblogs.com/sxdcgaq8080/p/5650404.html

classpath与filepath

Ref： https://blog.csdn.net/shangmingtao/article/details/78311189?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control

Spring容器

ApplicationContext通常的实现是什么

FileSystemXmlApplicationContext
ClassPathXmlApplicationContext
WebXmlApplicationContext

BeanFactory 和 ApplicationContext有什么区别

1、依赖关系

ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，还提供了更完整的框架功能：

继承MessageSource，因此支持国际化。
统一的资源文件访问方式。
提供在监听器中注册bean的事件。
同时加载多个配置文件。
载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的web层。

2、加载方式

BeanFactory采用延迟加载的方式，只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。

ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。

3、创建方式

BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用ContextLoader。

4、注册方式

BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。

Spring自动注册与自动装配

1）context: annotation-config/>

这个标签会自动向Spring容器注册以下四个BeanPostProcessor，让系统识别对应的注解从而支持相关的自动装配：

BeanPostProcessor	对应的注解
AutowiredAnnotationBeanPostProcessor	@Autowired
CommonAnnotationBeanPostProcessor	@Resource @PostConstruct @PreDestroy
PersistenceAnnotationBeanPostProcessor	@PersistenceUnit @PersistenceContext
RequiredAnnotationBeanPostProcessor	@Required

传统的注册方式：

1
2
3
4
1 <bean class="org.springframework.beans.factory.annotation. AutowiredAnnotationBeanPostProcessor"/>
2 <bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"/>
3 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
4 <bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>

这个标签只支持自动装配，不支持自动注册（因为不能识别@Component, @Controller, @Service, @Repository；要想识别这四个注解，需要配置<context: component-scan base-package="xxx.xxx"/>标签，见2。）。 2）<context: component-scan base-package="xxx.xxx"/>

这个标签包含了<context: annotation-config/>的功能；既支持自动装配，又支持自动注册。

支持@Component, @Controller, @Service, @Repository, @RestController, @ControllerAdvice, @Configuration注解。

作用：扫描base-package并在application context中注册扫描到的使用了以上注解的beans。

注意：Spring容器默认关闭注解装配。可以使用1或2开启注解装配。

3）mvc: annotation-driven

这个标签会自动注册以下bean：

DefaulAnnotationHandlerMapping
AnnotationMethodHandlerAdapter

这是Spring MVC为@Controller, @RequestMapping分发请求所必需的。

Ref: Spring自动注册及自动装配

自动装配的局限性

重写：你仍需用和配置来定义依赖，意味着总要重写自动装配。

基本数据类型：你不能自动装配简单的属性，如基本数据类型，String字符串，和类。

模糊特性：自动装配不如显式装配精确，如果有可能，建议使用显式装配。

Spring Beans

Spring支持的几种bean的作用域

Spring框架支持以下五种bean的作用域：

singleton bean在每个Spring ioc 容器中只有一个实例。
prototype 一个bean的定义可以有多个实例。
request 每次http请求都会创建一个bean，该作用域仅在基于web的Spring ApplicationContext情形下有效。
session 在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。
global-session 在一个全局的HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

Spring框架中的单例bean是线程安全的吗

不是，实际上大部分时候 spring bean 无状态的（比如 dao 类）。

Bean的生命周期

创建对象
BeanDefinition
填充属性
回调aware方法
初始化（InitializingBean接口）
aop 单例池（Map）

Spring中的 bean生命周期**?**

生命周期图

周期流程图

Bean的声明周期流程

Bean 容器找到配置文件中 Spring Bean 的定义。
Bean 容器利用 Java Reflection API 创建一个Bean的实例。
如果涉及到一些属性值利用 set() 方法设置一些属性值。
如果 Bean 实现了 BeanNameAware 接口，调用 setBeanName() 方法，传入Bean的名字。如果 Bean 实现了 BeanClassLoaderAware 接口，调用 setBeanClassLoader() 方法，传入ClassLoader 对象的实例。
与上面的类似，如果实现了其他 *.Aware 接口，就调用相应的方法。如果有和加载这个 Bean 的 Spring 容器相关的 BeanPostProcessor 对象，执行 postProcessBeforeInitialization() 方法
如果Bean实现了 InitializingBean 接口，执行 afterPropertiesSet() 方法。
如果 Bean 在配置文件中的定义包含 init-method 属性，执行指定的方法。
如果有和加载这个 Bean的 Spring 容器相关的 BeanPostProcessor 对象，执行 postProcessAfterInitialization() 方法
当要销毁 Bean 的时候，如果 Bean 实现了 DisposableBean 接口，执行 destroy() 方法。当要销毁 Bean 的时候，如果 Bean 在配置文件中的定义包含 destroy-method 属性，执行指定的方法。
Ref: Spring Bean的声明周期（Demo）

spring的策略设计模式

spring在初始化bean的过程中，需要大量调用BeanPostProcessor后置处理器，所有的后置处理器都有各自的实现方法

spring循环依赖

三级缓存，1、2、半成品的工厂（代理，用于定制bean）Map；3、三级缓存用于直接拿去成品的bean，不用重复之前复杂的过程

单例池（singleObjects）

单例对象只会实例化一次所以需要一个单例池来缓存

单例构造函数依赖和原型构造函数依赖

Ref: https://mp.weixin.qq.com/s/PmLWtSBr8PlmbZ0rOJ1ncw

FactoryBean和ObjectFactory

FactoryBean和ObjectFactory都是用来取得Bean，但使用的方法和地方不同，FactoryBean被配置好后，Spring调用getObject()方法来取得Bean，ObjectFactory配置好后，在Bean里面可以取得ObjectFactory实例，需要我们手动来调用getObject()来取得Bean。

Ref: BeanFactory和Factory Bean的区别

Spring如何实现单例

单例注册表+锁

https://www.cnblogs.com/twoheads/p/9723543.html

InitializingBean接口

参考：https://blog.csdn.net/weixin_30808575/article/details/96162918

其方法afterPropertiesSet是在init-method方法之前执行。

而BeanPostProcessor接口的postProcessBeforeInitialization方法在afterPropertiesSet方法之前执行

BeanPostProcessor，针对所有Spring上下文中所有的bean，可以在配置文档applicationContext.xml中配置一个BeanPostProcessor，然后对所有的bean进行一个初始化之前和之后的代理。 BeanPostProcessor接口中有两个方法： postProcessBeforeInitialization和postProcessAfterInitialization。 postProcessBeforeInitialization方法在bean初始化之前执行， postProcessAfterInitialization方法在bean初始化之后执行。

@PostConstruct

通过 debug 和调用栈找到类InitDestroyAnnotationBeanPostProcessor, 其中的核心方法，即 @PostConstruct 方法调用的入口：

从命名上，我们就可以得到某些信息——这是一个BeanPostProcessor。想到了什么？在也谈Spring容器的生命周期中，提到过BeanPostProcessor的postProcessBeforeInitialization是在Bean生命周期中afterPropertiesSet和init-method之前被调用的。另外通过跟踪，@PostConstruct方法的调用方式也是通过发射机制。

spring bean的初始化执行顺序：构造方法 --> @PostConstruct注解的方法 --> afterPropertiesSet方法 --> init-method指定的方法。具体可以参考例子
afterPropertiesSet通过接口实现方式调用（效率上高一点），@PostConstruct和init-method都是通过反射机制调用 构造方法 -> @Autowired -> @PostConstruct

https://www.cnblogs.com/pipicai96/p/11718761.html

BeanPostProcessor和BeanFactoryPostProcessor

参考书P155

BeanFacotoryProcessor的处理要区分两种情况：

通过硬编码方式的处理
通过配置文件方式的处理不但要实现注册功能，还要实现对后处理器的激活操作，所以需要载入配置中的定义，并进行激活

对于BeanPostProcessor并不需要马上调用，且硬编码的方式实现的功能是将后处理器提取并调用，这里不需要调用，当然不需要考虑硬编码的方式了，这里的功能只需要将配置文件的BeanPostProcessor提取出来并注册进入beanFacotry就可以了。

ApplicationListener

参考：https://blog.csdn.net/wo541075754/article/details/71720984

在一些业务场景中，当容器初始化完成之后，需要处理一些操作，比如一些数据的加载、初始化缓存、特定任务的注册等等。这个时候我们就可以使用Spring提供的ApplicationListener来进行操作。

代理

【Spring IOC---AOP代理对象生成的时机_gongsenlin341的博客-CSDN博客_spring 代理对象什么时候生成】https://blog.csdn.net/gongsenlin341/article/details/111240114

【在spring中获取代理对象代理的目标对象工具类 - 养眼大魔王 - 博客园】https://www.cnblogs.com/damowang/p/4172733.html

事务

Spring支持两种类型的事务管理

编程式事务管理：这意味你通过编程的方式管理事务，给你带来极大的灵活性，但是难维护。

声明式事务管理：这意味着你可以将业务代码和事务管理分离，你只需用注解和XML配置来管理事务。

spring事务不生效原因

https://zhuanlan.zhihu.com/p/101396825

https://mp.weixin.qq.com/s/SW7vEoEZcvwzBERWDV7HUQ

调用自身方法
方法不是public
发生错误异常(默认回滚的是RuntimeException，如果是其他异常想要回滚，需要在@Transactional注解上加rollbackFor属性)
数据库不支持事务毕竟spring事务用的是数据库的事

如何保证事务获取同一个Connection

ThreadLocal中

1
DataSourceUtils.getConnection(obtainDataSource());

spring的事务和数据库的事务隔离是一个概念吗

概念一样，数据库有四种隔离级别。spring在此基础上抽象出一种隔离级别为default，表示以数据库默认配置为主。

but如果spring配置的隔离级别与数据库不一致，以spring配置的为主。因为JDBC有一个接口：

1
void setTransactionIsolation(int level) throws SQLException;

该接口用来设置事务的隔离级别。那么在DataSourceUtils中，有一段代码是这样的

1
2
3
4
5
6
7
8
9
// Apply specific isolation level, if any.
Integer previousIsolationLevel = null;
if (definition != null && definition.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT) {
  int currentIsolation = con.getTransactionIsolation();
  if (currentIsolation != definition.getIsolationLevel()) {
    previousIsolationLevel = currentIsolation;
    con.setTransactionIsolation(definition.getIsolationLevel());
  }
}

Spring的事务传播行为

① PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

② PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。

③ PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

④ PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

⑤ PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

⑥ PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

⑦ PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按REQUIRED属性执行。

事务传播机制

举例：一个方法开启了事务，调用另一开启事务的方法，当传播行为不一样时，事务怎么执行？有几个事务

事务多线程如何生效

参考：https://blog.csdn.net/u010963948/article/details/80367020

总结：事务里开多线程，事务不生效（只能手动设置线程setUncaughtExceptionHandler方法异常时手动回滚）线程中开事务生效。

数据库连接和java多线程的关系

参考：https://blog.csdn.net/luanlouis/article/details/90760372

Java中，当然一个线程可以在整个生命周期独占一个java.sql.Connection，使用该对象完成各种数据库操作，因为一个线程内的所有操作都是同步的和线性的。然而，在实际的项目中，并不会这样做，原因有两个：

Java中的线程数量可能远超数据库连接数量，会出现僧多粥少的情况
Java线程在工作过程中，真正访问JDBC数据库连接所占用的时间比例很短

结合上述的两个症结，为了提高JDBC数据库连接的使用效率，目前普遍的解决方案是：当线程需要做数据库操作时，才会真正请求获取JDBC数据库连接,线程使用完了之后，立即释放，被释放的JDBC数据库连接等待下次分配使用

基于这个结论，会衍生两个问题需要解决：

1、Java多线程访问同一个java.sql.Connection会有什么问题？如何解决？ 1）事务错乱——锁解决

2）提交其它事务未提交的事务——确保每个线程在使用Connection对象时，最终要明确对Connection做commit 或者rollback。

2、JDBC数据库连接如何管理和分配？连接池

5.5.2.2 - 04.Spring定时任务

概述

有时候需要一些定时任务完成一些功能

@Scheduled注解用于定时计划完成一些任务。

Scheduled定时任务器

Scheduled简介

1
org.springframework.scheduling.annotation.Scheduled

spring.context依赖下的包org.springframework.scheduling，该包有4个子包： 1、annotation

定义了调度、异步任务相关的注解和解析类，常用的注解如@Async、@EnableAsync、@EnableScheduling和@Scheduled。

2、concurrent

定义了调度任务执行器和相对应的FactoryBean

3、config

定义了配置解析、任务具体实现类、调度任务XML配置文件解析相关的解析类。4、4、support

定义了反射支持类、Cron表达式解析器等工具类。

Scheduled使用

1、依赖

如果想单独使用Scheduling，只需要引入spring-context这个依赖。

springboot引入spring-boot-starter-web已经集成了spring-context，可以直接使用Scheduling模块。

2、在需要定期执行的方法上标注 @Schduled

1
2
3
4
5
6
7
@Component
public class ScheduledDemo {
    @Scheduled(cron = "0/5 * * ? * *")
    public void run() {
        System.out.println("this is scheduled ");
    }
}

3、开启Schedule 开启Scheduling模块支持只需要在某一个配置类中添加@EnableScheduling注解即可，一般为了明确模块的引入，建议在启动类中使用此注解。

1
2
3
4
5
6
7
8
# 在启动类上标注
@EnableScheduling
@SpringBootApplication
public class BootdemoApplication {
   public static void main(String[] args) {
      SpringApplication.run(BootdemoApplication.class, args);
   }
}

注意：默认是单线程执行，即同一时刻只有一个定时任务。如果一个定时任务是一直在运行，则其它定时任务将被阻塞一直无法运行。

触发规则

1、TriggerTask：动态定时任务。通过Trigger#nextExecutionTime 给定的触发上下文确定下一个执行时间。

2、CronTask：动态定时任务，TriggerTask子类。通过cron表达式确定的时间触发下一个任务执行。

3、IntervalTask：一定时间延迟之后，周期性执行的任务。

多线程使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler;
import java.util.concurrent.ThreadPoolExecutor;
@Configuration
public class TaskSchedule {
    @Bean
    public TaskScheduler scheduledExecutorService() { // taskScheduler()
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler(); 
        scheduler.setPoolSize(5); // 注意：默认只有一个线程
        scheduler.setThreadNamePrefix("scheduled-thread-");
        scheduler.setWaitForTasksToCompleteOnShutdown(true);
        scheduler.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        return scheduler;
    }
}

注意事项

1、其它注入不同名的TaskScheduler的bean

2、自动注入扫描路径

3、注入优先级

4、注解方法为public

Quartz定时任务框架

Quartz的使用思路

1、job：任务

2、Trigger：触发器

3、Scheduler：任务调度

Quartz使用

1、依赖

1
2
3
4
5
6
<!-- https://mvnrepository.com/artifact/org.quartz-scheduler/quartz -->
<dependency>
    <groupId>org.quartz-scheduler</groupId>
    <artifactId>quartz</artifactId>
    <version>2.2.0</version>
</dependency>

2、创建执行任务

1
2
3
4
5
6
7
import org.quartz.*;
public class QuartzDemo implements Job {
    @Override
    public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
        System.out.println("QuartzDemo execute");
    }
}

3、配置触发器并启动任务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
import org.quartz.*;
import org.quartz.impl.StdSchedulerFactory;
public class QuartzMain {
    public static void main(String[] args) throws Exception {
        // 1、创建Job对象
        JobDetail jobDetail = JobBuilder.newJob(QuartzDemo.class).build();
        // 2、创建Trigger对象
        Trigger trigger = TriggerBuilder.newTrigger()
//                .withSchedule(SimpleScheduleBuilder.repeatSecondlyForever())
                .withSchedule(CronScheduleBuilder.cronSchedule("0/5 * * ? * *"))
                .build();
        // 3、创建Scheduler对象
        Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
        scheduler.scheduleJob(jobDetail, trigger);
        scheduler.start();
    }
}

Springboot整合Quartz使用

1、依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<dependency>
   <groupId>org.quartz-scheduler</groupId>
   <artifactId>quartz</artifactId>
   <version>2.2.0</version>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-context-support</artifactId>
   <version>4.3.17.RELEASE</version>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-tx</artifactId>
   <version>4.3.17.RELEASE</version>
</dependency>

2、创建执行任务QuartzDemo 同上

3、配置触发器Bean

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package com.huangbo.bootdemo.scheduled;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.quartz.CronTriggerFactoryBean;
import org.springframework.scheduling.quartz.JobDetailFactoryBean;
import org.springframework.scheduling.quartz.SchedulerFactoryBean;
import org.springframework.scheduling.quartz.SimpleTriggerFactoryBean;
@Configuration //注意别写成了Component
public class QuartzConfig {
    @Bean
    public JobDetailFactoryBean jobDetailFactoryBean() {
        JobDetailFactoryBean factoryBean = new JobDetailFactoryBean();
        factoryBean.setJobClass(QuartzDemo.class);
        return factoryBean;
    }
    @Bean
    public SimpleTriggerFactoryBean simpleTriggerFactoryBean(JobDetailFactoryBean jobDetailFactoryBean) {
        SimpleTriggerFactoryBean factoryBean = new SimpleTriggerFactoryBean();
        factoryBean.setJobDetail(jobDetailFactoryBean.getObject());
        factoryBean.setRepeatInterval(3000); // ms
        factoryBean.setRepeatCount(10);
        return factoryBean;
    }
    @Bean
    public CronTriggerFactoryBean cronTriggerFactoryBean(JobDetailFactoryBean jobDetailFactoryBean) {
        CronTriggerFactoryBean factoryBean = new CronTriggerFactoryBean();
        factoryBean.setJobDetail(jobDetailFactoryBean.getObject());
        factoryBean.setCronExpression("0/5 * * ? * *");
        return factoryBean;
    }
    @Bean
    public SchedulerFactoryBean schedulerFactoryBean(CronTriggerFactoryBean cronTriggerFactoryBean) {
        SchedulerFactoryBean factoryBean = new SchedulerFactoryBean();
        factoryBean.setTriggers(cronTriggerFactoryBean.getObject());
        return factoryBean;
    }
}

4、启动

1
2
3
4
5
6
7
@EnableScheduling
@SpringBootApplication
public class BootdemoApplication {
   public static void main(String[] args) {
      SpringApplication.run(BootdemoApplication.class, args);
   }
}

Scheduled原理

Scheduling模块工作流程

Scheduling模块的核心逻辑在ScheduledAnnotationBeanPostProcessor和ScheduledTaskRegistrar两个类中

入口

EnableScheduling注解

1
2
3
4
5
6
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
@Documented
public @interface EnableScheduling {
}

然后看导入的类 SchedulingConfiguration 这里有个技巧：Spring内部加载的Bean一般会定义名称为internalXXX，Bean的role会定义为ROLE_INFRASTRUCTURE = 2

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
// org.springframework.scheduling.annotation.SchedulingConfiguration
@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class SchedulingConfiguration {
   @Bean(name = TaskManagementConfigUtils.SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
   @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
   public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
      return new ScheduledAnnotationBeanPostProcessor();
   }
}

看 ScheduledAnnotationBeanPostProcessor 构造方法，初始化了 register

1
2
3
public ScheduledAnnotationBeanPostProcessor() {
   this.registrar = new ScheduledTaskRegistrar();
}

ScheduledAnnotationBeanPostProcessor

实现的接口

ScheduledTaskHolder

返回Set，表示持有的所有任务实例。

MergedBeanDefinitionPostProcessor接口：Bean定义合并时回调，预留空实现，暂时不做任何处理。

BeanPostProcessor

也就是MergedBeanDefinitionPostProcessor的父接口，Bean实例初始化前后分别回调，其中，后回调的postProcessAfterInitialization()方法就是用于解析@Scheduled和装载ScheduledTask，需要重点关注此方法的逻辑。

DestructionAwareBeanPostProcessor

具体的Bean实例销毁的时候回调，用于Bean实例销毁的时候移除和取消对应的任务实例。

Ordered接口：用于Bean加载时候的排序，主要是改变ScheduledAnnotationBeanPostProcessor在BeanPostProcessor执行链中的顺序。

EmbeddedValueResolverAware

回调StringValueResolver实例，用于解析带占位符的环境变量属性值。

BeanNameAware

回调BeanName。

BeanFactoryAware

回调BeanFactory实例，具体是DefaultListableBeanFactory，也就是熟知的IOC容器。

ApplicationContextAware

回调ApplicationContext实例，也就是熟知的Spring上下文，它是IOC容器的门面，同时是事件广播器、资源加载器的实现等等。

SmartInitializingSingleton

所有单例实例化完毕之后回调，作用是在持有的applicationContext为NULL的时候开始调度所有加载完成的任务，这个钩子接口十分有用，常用做一些资源初始化工作。

ApplicationListener

监听Spring应用的事件，具体是ApplicationListener，监听上下文刷新的事件，如果事件中携带的ApplicationContext实例和ApplicationContextAware回调的ApplicationContext实例一致，那么在此监听回调方法中开始调度所有加载完成的任务，也就是在ScheduledAnnotationBeanPostProcessor这个类中，SmartInitializingSingleton接口的实现和ApplicationListener接口的实现逻辑是互斥的。

DisposableBean

当前Bean实例销毁时候回调，也就是ScheduledAnnotationBeanPostProcessor自身被销毁的时候回调，用于取消和清理所有的ScheduledTask。

@Scheduled注解解析

在postProcessAfterInitialization方法中

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// org.springframework.scheduling.annotation.ScheduledAnnotationBeanPostProcessor#postProcessAfterInitialization
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
   // 忽略AopInfrastructureBean、TaskScheduler和ScheduledExecutorService三种类型的Bean
   if (bean instanceof AopInfrastructureBean || bean instanceof TaskScheduler ||
         bean instanceof ScheduledExecutorService) {
      // Ignore AOP infrastructure such as scoped proxies.
      return bean;
   }
   // 获取Bean的用户态类型，例如Bean有可能被CGLIB增强，这个时候要取其父类
   Class<?> targetClass = AopProxyUtils.ultimateTargetClass(bean);
   // nonAnnotatedClasses存放不包含@Scheduled注解的类型，缓存起来避免重复判断它是否携带@Scheduled注解的方法
   if (!this.nonAnnotatedClasses.contains(targetClass) &&
         AnnotationUtils.isCandidateClass(targetClass, Arrays.asList(Scheduled.class, Schedules.class))) {
      // JDK8之后支持重复注解，因此获取具体类型中Method -> @Scheduled的集合，也就是有可能一个方法使用多个@Scheduled注解，最终会封装为多个Task
      Map<Method, Set<Scheduled>> annotatedMethods = MethodIntrospector.selectMethods(targetClass,
            (MethodIntrospector.MetadataLookup<Set<Scheduled>>) method -> {
               Set<Scheduled> scheduledMethods = AnnotatedElementUtils.getMergedRepeatableAnnotations(
                     method, Scheduled.class, Schedules.class);
               return (!scheduledMethods.isEmpty() ? scheduledMethods : null);
            });
      // 解析到类型中不包含@Scheduled注解的方法添加到nonAnnotatedClasses缓存中
      if (annotatedMethods.isEmpty()) {
         this.nonAnnotatedClasses.add(targetClass);
         if (logger.isTraceEnabled()) {
            logger.trace("No @Scheduled annotations found on bean class: " + targetClass);
         }
      }
      // Method -> @Scheduled的集合遍历processScheduled()方法进行登记
      else {
         // Non-empty set of methods
         annotatedMethods.forEach((method, scheduledMethods) ->
               scheduledMethods.forEach(scheduled -> processScheduled(scheduled, method, bean)));
         if (logger.isTraceEnabled()) {
            logger.trace(annotatedMethods.size() + " @Scheduled methods processed on bean '" + beanName +
                  "': " + annotatedMethods);
         }
      }
   }
   return bean;
}

processScheduled方法就是具体的注解解析和Task封装的方法。该方法主要做了4件事：

1、解析@Scheduled中的initialDelay、initialDelayString属性，适用于FixedDelayTask或者FixedRateTask的延迟执行

2、优先解析@Scheduled中的cron属性，封装为CronTask，通过ScheduledTaskRegistrar进行缓存

3、解析@Scheduled中的fixedDelay、fixedDelayString属性，封装为FixedDelayTask，通过ScheduledTaskRegistrar进行缓存

4、解析@Scheduled中的fixedRate、fixedRateString属性，封装为FixedRateTask，通过ScheduledTaskRegistrar进行缓存

Expand/Collapse Code Block

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
// org.springframework.scheduling.annotation.ScheduledAnnotationBeanPostProcessor#processScheduled
protected void processScheduled(Scheduled scheduled, Method method, Object bean) {
   try {
      // 通过方法宿主Bean和目标方法封装Runnable适配器ScheduledMethodRunnable实例
      Runnable runnable = createRunnable(bean, method);
      boolean processedSchedule = false;
      String errorMessage =
            "Exactly one of the 'cron', 'fixedDelay(String)', or 'fixedRate(String)' attributes is required";
      // 缓存已经装载的任务
      Set<ScheduledTask> tasks = new LinkedHashSet<>(4);
      // Determine initial delay
      // 解析初始化延迟执行时间，initialDelayString支持占位符配置，如果initialDelayString配置了，会覆盖initialDelay的值
      long initialDelay = scheduled.initialDelay();
      String initialDelayString = scheduled.initialDelayString();
      if (StringUtils.hasText(initialDelayString)) {
         Assert.isTrue(initialDelay < 0, "Specify 'initialDelay' or 'initialDelayString', not both");
         if (this.embeddedValueResolver != null) {
            initialDelayString = this.embeddedValueResolver.resolveStringValue(initialDelayString);
         }
         if (StringUtils.hasLength(initialDelayString)) {
            try {
               initialDelay = parseDelayAsLong(initialDelayString);
            }
            catch (RuntimeException ex) {
               throw new IllegalArgumentException(
                     "Invalid initialDelayString value \"" + initialDelayString + "\" - cannot parse into long");
            }
         }
      }
      // Check cron expression
      // 解析时区zone的值，支持支持占位符配置，判断cron是否存在，存在则装载为CronTask
      String cron = scheduled.cron();
      if (StringUtils.hasText(cron)) {
         String zone = scheduled.zone();
         if (this.embeddedValueResolver != null) {
            cron = this.embeddedValueResolver.resolveStringValue(cron);
            zone = this.embeddedValueResolver.resolveStringValue(zone);
         }
         if (StringUtils.hasLength(cron)) {
            Assert.isTrue(initialDelay == -1, "'initialDelay' not supported for cron triggers");
            processedSchedule = true;
            if (!Scheduled.CRON_DISABLED.equals(cron)) {
               TimeZone timeZone;
               if (StringUtils.hasText(zone)) {
                  timeZone = StringUtils.parseTimeZoneString(zone);
               }
               else {
                  timeZone = TimeZone.getDefault();
               }
               // 此方法虽然表面上是调度CronTask，实际上由于ScheduledTaskRegistrar不持有TaskScheduler，只是把任务添加到它的缓存中
               // 返回的任务实例添加到宿主Bean的缓存中，然后最后会放入宿主Bean -> List<ScheduledTask>映射中
               tasks.add(this.registrar.scheduleCronTask(new CronTask(runnable, new CronTrigger(cron, timeZone))));
            }
         }
      }
      // At this point we don't need to differentiate between initial delay set or not anymore
      // 修正小于0的初始化延迟执行时间值为0
      if (initialDelay < 0) {
         initialDelay = 0;
      }
      // Check fixed delay
      // 解析fixedDelay和fixedDelayString，如果同时配置，fixedDelayString最终解析出来的整数值会覆盖fixedDelay，封装为FixedDelayTask
      long fixedDelay = scheduled.fixedDelay();
      if (fixedDelay >= 0) {
         Assert.isTrue(!processedSchedule, errorMessage);
         processedSchedule = true;
         tasks.add(this.registrar.scheduleFixedDelayTask(new FixedDelayTask(runnable, fixedDelay, initialDelay)));
      }
      String fixedDelayString = scheduled.fixedDelayString();
      if (StringUtils.hasText(fixedDelayString)) {
         if (this.embeddedValueResolver != null) {
            fixedDelayString = this.embeddedValueResolver.resolveStringValue(fixedDelayString);
         }
         if (StringUtils.hasLength(fixedDelayString)) {
            Assert.isTrue(!processedSchedule, errorMessage);
            processedSchedule = true;
            try {
               fixedDelay = parseDelayAsLong(fixedDelayString);
            }
            catch (RuntimeException ex) {
               throw new IllegalArgumentException(
                     "Invalid fixedDelayString value \"" + fixedDelayString + "\" - cannot parse into long");
            }
            // 此方法虽然表面上是调度FixedDelayTask，实际上由于ScheduledTaskRegistrar不持有TaskScheduler，只是把任务添加到它的缓存中
            // 返回的任务实例添加到宿主Bean的缓存中，然后最后会放入宿主Bean -> List<ScheduledTask>映射中
            tasks.add(this.registrar.scheduleFixedDelayTask(new FixedDelayTask(runnable, fixedDelay, initialDelay)));
         }
      }
      // Check fixed rate
      // 解析fixedRate和fixedRateString，如果同时配置，fixedRateString最终解析出来的整数值会覆盖fixedRate，封装为FixedRateTask
      long fixedRate = scheduled.fixedRate();
      if (fixedRate >= 0) {
         Assert.isTrue(!processedSchedule, errorMessage);
         processedSchedule = true;
         tasks.add(this.registrar.scheduleFixedRateTask(new FixedRateTask(runnable, fixedRate, initialDelay)));
      }
      String fixedRateString = scheduled.fixedRateString();
      if (StringUtils.hasText(fixedRateString)) {
         if (this.embeddedValueResolver != null) {
            fixedRateString = this.embeddedValueResolver.resolveStringValue(fixedRateString);
         }
         if (StringUtils.hasLength(fixedRateString)) {
            Assert.isTrue(!processedSchedule, errorMessage);
            processedSchedule = true;
            try {
               fixedRate = parseDelayAsLong(fixedRateString);
            }
            catch (RuntimeException ex) {
               throw new IllegalArgumentException(
                     "Invalid fixedRateString value \"" + fixedRateString + "\" - cannot parse into long");
            }
            // 此方法虽然表面上是调度FixedRateTask，实际上由于ScheduledTaskRegistrar不持有TaskScheduler，只是把任务添加到它的缓存中
            // 返回的任务实例添加到宿主Bean的缓存中，然后最后会放入宿主Bean -> List<ScheduledTask>映射中
            tasks.add(this.registrar.scheduleFixedRateTask(new FixedRateTask(runnable, fixedRate, initialDelay)));
         }
      }
      // Check whether we had any attribute set
      Assert.isTrue(processedSchedule, errorMessage);
      // Finally register the scheduled tasks
      synchronized (this.scheduledTasks) {
         // 注册所有任务实例，这个映射Key为宿主Bean实例，Value为List<ScheduledTask>，后面用于调度所有注册完成的任务
         Set<ScheduledTask> regTasks = this.scheduledTasks.computeIfAbsent(bean, key -> new LinkedHashSet<>(4));
         regTasks.addAll(tasks);
      }
   }
   catch (IllegalArgumentException ex) {
      throw new IllegalStateException(
            "Encountered invalid @Scheduled method '" + method.getName() + "': " + ex.getMessage());
   }
}

@Scheduled修饰的某个方法如果同时配置了cron、fixedDelay|fixedDelayString和fixedRate|fixedRateString属性，意味着此方法同时封装为三种任务CronTask、FixedDelayTask和FixedRateTask。解析xxString值的使用，用到了EmbeddedValueResolver解析字符串的值，支持占位符，这样可以直接获取环境配置中的占位符属性（基于SPEL的特性，甚至可以支持嵌套占位符）。解析成功的所有任务实例存放在ScheduledAnnotationBeanPostProcessor的一个映射scheduledTasks中

finishRegistration

解析和缓存工作完成之后，接着分析最终激活所有调度任务的逻辑，见互斥方法afterSingletonsInstantiated()和onApplicationEvent()，两者中一定只有一个方法能够调用finishRegistration()

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
// org.springframework.scheduling.annotation.ScheduledAnnotationBeanPostProcessor
@Override  //所有单例实例化完毕之后回调
public void afterSingletonsInstantiated() { 
   this.nonAnnotatedClasses.clear();
   if (this.applicationContext == null) {
      finishRegistration();
   }
}
@Override  // 上下文刷新完成之后回调
public void onApplicationEvent(ContextRefreshedEvent event) {
   if (event.getApplicationContext() == this.applicationContext) {
      finishRegistration();
   }
}

private void finishRegistration() {
   // 如果持有的scheduler对象不为null则设置ScheduledTaskRegistrar中的任务调度器
   if (this.scheduler != null) {
      this.registrar.setScheduler(this.scheduler);
   }
   // 这个判断一般会成立，得到的BeanFactory就是DefaultListableBeanFactory
   if (this.beanFactory instanceof ListableBeanFactory) {
      // 获取所有的调度配置器SchedulingConfigurer实例，并且都回调configureTasks()方法，这个很重要，它是用户动态装载调取任务的扩展钩子接口
      Map<String, SchedulingConfigurer> beans =
            ((ListableBeanFactory) this.beanFactory).getBeansOfType(SchedulingConfigurer.class);
      List<SchedulingConfigurer> configurers = new ArrayList<>(beans.values());
      // SchedulingConfigurer实例列表排序
      AnnotationAwareOrderComparator.sort(configurers);
      for (SchedulingConfigurer configurer : configurers) {
         configurer.configureTasks(this.registrar);
      }
   }
   // 下面这一大段逻辑都是为了从BeanFactory取出任务调度器实例，主要判断TaskScheduler或者ScheduledExecutorService类型的Bean，包括尝试通过类型或者名字获取
   // 获取成功后设置到ScheduledTaskRegistrar中
   if (this.registrar.hasTasks() && this.registrar.getScheduler() == null) {
      Assert.state(this.beanFactory != null, "BeanFactory must be set to find scheduler by type");
      try {
         // Search for TaskScheduler bean...
         this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, false));
      }
      catch (NoUniqueBeanDefinitionException ex) {
         if (logger.isTraceEnabled()) {
            logger.trace("Could not find unique TaskScheduler bean - attempting to resolve by name: " +
                  ex.getMessage());
         }
         try {
            this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, true));
         }
         catch (NoSuchBeanDefinitionException ex2) {
            if (logger.isInfoEnabled()) {
               logger.info("More than one TaskScheduler bean exists within the context, and " +
                     "none is named 'taskScheduler'. Mark one of them as primary or name it 'taskScheduler' " +
                     "(possibly as an alias); or implement the SchedulingConfigurer interface and call " +
                     "ScheduledTaskRegistrar#setScheduler explicitly within the configureTasks() callback: " +
                     ex.getBeanNamesFound());
            }
         }
      }
      catch (NoSuchBeanDefinitionException ex) {
         if (logger.isTraceEnabled()) {
            logger.trace("Could not find default TaskScheduler bean - attempting to find ScheduledExecutorService: " +
                  ex.getMessage());
         }
         // Search for ScheduledExecutorService bean next...
         try {
            this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, false));
         }
         catch (NoUniqueBeanDefinitionException ex2) {
            if (logger.isTraceEnabled()) {
               logger.trace("Could not find unique ScheduledExecutorService bean - attempting to resolve by name: " +
                     ex2.getMessage());
            }
            try {
               this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, true));
            }
            catch (NoSuchBeanDefinitionException ex3) {
               if (logger.isInfoEnabled()) {
                  logger.info("More than one ScheduledExecutorService bean exists within the context, and " +
                        "none is named 'taskScheduler'. Mark one of them as primary or name it 'taskScheduler' " +
                        "(possibly as an alias); or implement the SchedulingConfigurer interface and call " +
                        "ScheduledTaskRegistrar#setScheduler explicitly within the configureTasks() callback: " +
                        ex2.getBeanNamesFound());
               }
            }
         }
         catch (NoSuchBeanDefinitionException ex2) {
            if (logger.isTraceEnabled()) {
               logger.trace("Could not find default ScheduledExecutorService bean - falling back to default: " +
                     ex2.getMessage());
            }
            // Giving up -> falling back to default scheduler within the registrar...
            logger.info("No TaskScheduler/ScheduledExecutorService bean found for scheduled processing");
         }
      }
   }
   // 调用ScheduledTaskRegistrar的afterPropertiesSet()方法，装载所有的调度任务
   this.registrar.afterPropertiesSet();
}

注意： 1、SchedulingConfigurer是调度模块提供给使用的进行扩展的钩子接口，用于在激活所有调度任务之前回调ScheduledTaskRegistrar实例，只要拿到ScheduledTaskRegistrar实例，我们就可以使用它注册和装载新的Task。

ScheduledTaskRegistrar

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// org.springframework.scheduling.config.ScheduledTaskRegistrar
@Override
public void afterPropertiesSet() {
   scheduleTasks();
}
@SuppressWarnings("deprecation")
protected void scheduleTasks() {
   // 注意：如果找不到任务调度器实例，那么会用单个线程调度所有任务
   if (this.taskScheduler == null) {
      this.localExecutor = Executors.newSingleThreadScheduledExecutor();
      this.taskScheduler = new ConcurrentTaskScheduler(this.localExecutor);
   }
   // 调度所有装载完毕的自定义触发器的任务实例
   if (this.triggerTasks != null) {
      for (TriggerTask task : this.triggerTasks) {
         addScheduledTask(scheduleTriggerTask(task));
      }
   }
   // 调度所有装载完毕的CronTask
   if (this.cronTasks != null) {
      for (CronTask task : this.cronTasks) {
         addScheduledTask(scheduleCronTask(task));
      }
   }
   // 调度所有装载完毕的FixedRateTask
   if (this.fixedRateTasks != null) {
      for (IntervalTask task : this.fixedRateTasks) {
         addScheduledTask(scheduleFixedRateTask(task));
      }
   }
   // 调度所有装载完毕的FixedDelayTask
   if (this.fixedDelayTasks != null) {
      for (IntervalTask task : this.fixedDelayTasks) {
         addScheduledTask(scheduleFixedDelayTask(task));
      }
   }
}

注意： 1、如果没有配置TaskScheduler或者ScheduledExecutorService类型的Bean，那么调度模块只会创建一个线程（默认执行器 ScheduledExecutorService）去调度所有装载完毕的任务，如果任务比较多，执行密度比较大，很有可能会造成大量任务饥饿，表现为存在部分任务不会触发调度的场景（这个是调度模块生产中经常遇到的故障，需要重点排查是否没有设置TaskScheduler或者ScheduledExecutorService，或者设置了单默认线程数据为1）。

schedule

这里使用schedule作为例子分析，其它类似方法大同小异，默认 ConcurrentTaskScheduler 类

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
// org.springframework.scheduling.concurrent.ConcurrentTaskScheduler
@Override
@Nullable
public ScheduledFuture<?> schedule(Runnable task, Trigger trigger) {
   try {
      if (this.enterpriseConcurrentScheduler) {
         return new EnterpriseConcurrentTriggerScheduler().schedule(decorateTask(task, true), trigger);
      }
      else {
         ErrorHandler errorHandler =
               (this.errorHandler != null ? this.errorHandler : TaskUtils.getDefaultErrorHandler(true));
         // 创建 ReschedulingRunnable 进行调度，并返回一个 ScheduledFuture
         return new ReschedulingRunnable(task, trigger, this.clock, this.scheduledExecutor, errorHandler).schedule();
      }
   }
   catch (RejectedExecutionException ex) {
      throw new TaskRejectedException("Executor [" + this.scheduledExecutor + "] did not accept task: " + task, ex);
   }
}

ReschedulingRunnable

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// org.springframework.scheduling.concurrent.ReschedulingRunnable
public ReschedulingRunnable(Runnable delegate, Trigger trigger, Clock clock,
      ScheduledExecutorService executor, ErrorHandler errorHandler) {
   // 设置调度器的任务和错误处理器
   super(delegate, errorHandler);
   this.trigger = trigger;
   this.triggerContext = new SimpleTriggerContext(clock);
   this.executor = executor;
}
@Nullable
public ScheduledFuture<?> schedule() {
   synchronized (this.triggerContextMonitor) {
      // 计算下次调用时间，会用到前面保存过的调用时间进行计算
      this.scheduledExecutionTime = this.trigger.nextExecutionTime(this.triggerContext);
      if (this.scheduledExecutionTime == null) {
         return null;
      }
      long initialDelay = this.scheduledExecutionTime.getTime() - this.triggerContext.getClock().millis();
      //进行调度，调用这个类本身，而不是根据需要调用方法创建出来的调度对象
      this.currentFuture = this.executor.schedule(this, initialDelay, TimeUnit.MILLISECONDS);
      return this;
   }
}
@Override
public void run() {
   // 当前时间
   Date actualExecutionTime = new Date(this.triggerContext.getClock().millis());
   // 父类run方法，会调用需要调用方法创建出来的调度对象
   super.run();
   Date completionTime = new Date(this.triggerContext.getClock().millis());
   synchronized (this.triggerContextMonitor) {
      Assert.state(this.scheduledExecutionTime != null, "No scheduled execution");
      // 更新调用时间
      this.triggerContext.update(this.scheduledExecutionTime, actualExecutionTime, completionTime);
      // 检查方法是否取消
      if (!obtainCurrentFuture().isCancelled()) {
         // 类本身的调度，刷新下次调用时间
         schedule();
      }
   }
}

Reference

Scheduled的多线程实现

Scheduled注解的原理分析

Scheduled的实现原理

5.5.2.3 - 12.Spring扩展

Spring启动流程

Bean作为Spring Framework的核心，其生命周期可以分为五个主干流程：

1、容器启动阶段（严格来讲这个不属于Bean的生命周期）

2、Bean（单例非懒加载）的实例化阶段

3、Bean的属性注入阶段

4、Bean的初始化阶段

5、Bean的销毁阶段

Spring容器启动流程

扩展接口启动调用顺序图

ApplicationContextInitializer

1
2
3
4
5
6
7
8
// org.springframework.context.ApplicationContextInitializer
public interface ApplicationContextInitializer<C extends ConfigurableApplicationContext> {
   /**
    * Initialize the given application context.
    * @param applicationContext the application to configure
    */
   void initialize(C applicationContext);
}

功能

spring容器在刷新之前初始化 ConfigurableApplicationContext 的回调接口，简单来说，就是在容器刷新之前调用此类的 initialize 方法。用户可以在整个spring容器还没被初始化之前做一些事情。

使用场景：

在最开始激活一些配置，或者利用这时候class还没被类加载器加载的时机，进行动态字节码注入等操作。

代码示例

1
2
3
4
5
6
public class MyApplicationContextInitializer implements ApplicationContextInitializer {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        System.out.println("MyApplicationContextInitializer");
    }
}

因为这时候spring容器还没被初始化，所以想要自己的扩展的生效，有以下三种方式： 1、在启动类中用加入

1
springApplication.addInitializers(new TestApplicationContextInitializer())

2、配置文件配置

1
context.initializer.classes=com.example.demo.TestApplicationContextInitializer

3、Spring SPI扩展，在spring.factories中加入

1
org.springframework.context.ApplicationContextInitializer=com.example.demo.TestApplicationContextInitializer

BeanDefinitionRegistryPostProcessor

功能

该接口在读取项目中的beanDefinition之后执行，提供一个补充的扩展点

使用场景：你可以在这里动态注册自己的beanDefinition，可以加载classpath之外的bean

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
public class TestBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor {
    @Override
    public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
        System.out.println("[BeanDefinitionRegistryPostProcessor] postProcessBeanDefinitionRegistry");
    }
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        System.out.println("[BeanDefinitionRegistryPostProcessor] postProcessBeanFactory");
    }
}

BeanFactoryPostProcessor

功能

该接口是beanFactory的扩展接口，调用时机在spring在读取beanDefinition信息之后，实例化bean之前。

用户可以通过实现这个扩展接口来自行处理一些东西，比如修改已经注册的beanDefinition的元信息。

代码示例

1
2
3
4
5
6
public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        System.out.println("MyBeanFactoryPostProcessor");
    }
}

InstantiationAwareBeanPostProcessor

功能

该接口继承了BeanPostProcess接口，区别如下：

BeanPostProcess接口只在bean的初始化阶段进行扩展（注入spring上下文前后），而InstantiationAwareBeanPostProcessor接口在此基础上增加了3个方法，把可扩展的范围增加了实例化阶段和属性注入阶段。

该类主要的扩展点有以下5个方法，主要在bean生命周期的两大阶段：实例化阶段和初始化阶段，下面一起进行说明，按调用顺序为：

1、postProcessBeforeInstantiation：实例化bean之前，相当于new这个bean之前

2、postProcessAfterInstantiation：实例化bean之后，相当于new这个bean之后

3、postProcessPropertyValues：bean已经实例化完成，在属性注入时阶段触发@Autowired, @Resource等注解原理基于此方法实现

4、postProcessBeforeInitialization：初始化bean之前，相当于把bean注入spring上下文之前

5、postProcessAfterInitialization：初始化bean之后，相当于把bean注入spring上下文之后

使用场景：

无论是写中间件和业务，都能利用这个特性。比如对实现了某一类接口的bean在各个生命期间进行收集，或者对某个类型的bean进行统一的设值等等。

代码

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class MyInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("[MyInstantiationAwareBeanPostProcessor] postProcessBeforeInitialization " + beanName);
        return bean;
    }
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("[MyInstantiationAwareBeanPostProcessor] postProcessAfterInitialization " + beanName);
        return bean;
    }
    @Override
    public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
        System.out.println("[MyInstantiationAwareBeanPostProcessor] postProcessBeforeInstantiation " + beanName);
        return null;
    }
    @Override
    public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
        System.out.println("[MyInstantiationAwareBeanPostProcessor] postProcessAfterInstantiation " + beanName);
        return true;
    }
    @Override
    public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
        System.out.println("[MyInstantiationAwareBeanPostProcessor] postProcessPropertyValues " + beanName);
        return pvs;
    }
}

SmartInstantiationAwareBeanPostProcessor

功能

该扩展接口有3个触发点方法

1、predictBeanType

该触发点发生在postProcessBeforeInstantiation之前(在图上并没有标明，因为一般不太需要扩展这个点)，这个方法用于预测Bean的类型，返回第一个预测成功的Class类型，如果不能预测返回null；当你调用BeanFactory.getType(name)时当通过bean的名字无法得到bean类型信息时就调用该回调方法来决定类型信息。

2、determineCandidateConstructors

该触发点发生在postProcessBeforeInstantiation之后，用于确定该bean的构造函数之用，返回的是该bean的所有构造函数列表。用户可以扩展这个点，来自定义选择相应的构造器来实例化这个bean。

3、getEarlyBeanReference

该触发点发生在postProcessAfterInstantiation之后，当有循环依赖的场景，当bean实例化好之后，为了防止有循环依赖，会提前暴露回调方法，用于bean实例化的后置处理。这个方法就是在提前暴露的回调方法中触发。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
public class MySmartInstantiationAwareBeanPostProcessor implements SmartInstantiationAwareBeanPostProcessor {
    @Override
    public Class<?> predictBeanType(Class<?> beanClass, String beanName) throws BeansException {
        System.out.println("[MySmartInstantiationAwareBeanPostProcessor] predictBeanType " + beanName);
        return beanClass;
    }
    @Override
    public Constructor<?>[] determineCandidateConstructors(Class<?> beanClass, String beanName) throws BeansException {
        System.out.println("[MySmartInstantiationAwareBeanPostProcessor] determineCandidateConstructors " + beanName);
        return null;
    }
    @Override
    public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        System.out.println("[MySmartInstantiationAwareBeanPostProcessor] getEarlyBeanReference " + beanName);
        return bean;
    }
}

BeanFactoryAware

功能

该类只有一个触发点，发生在bean的实例化之后，注入属性之前，也就是Setter之前。这个类的扩展点方法为 setBeanFactory，可以拿到BeanFactory这个属性。

使用场景：

可以在bean实例化之后，但还未初始化之前，拿到 BeanFactory，然后可以对每个bean作特殊化的定制。也或者可以把BeanFactory拿到进行缓存，日后使用。

代码示例

1
2
3
4
5
6
7
8
public class BeanFactoryHolder implements BeanFactoryAware {
    private static BeanFactory beanFactory;
    @Override
    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
        this.beanFactory = beanFactory;
        System.out.println("[BeanFactoryHolder] " + beanFactory.getBean(TestBeanFactoryAware.class).getClass().getSimpleName());
    }
}

ApplicationContextAwareProcessor

EnvironmentAware

功能

用于获取EnviromentAware的一个扩展类，这个变量非常有用，可以获得系统内的所有参数。当然个人认为这个Aware没必要去扩展，因为spring内部都可以通过注入的方式来直接获得。

EmbeddedValueResolverAware

功能

用于获取StringValueResolver的一个扩展类， StringValueResolver用于获取基于String类型的properties的变量，一般我们都用@Value的方式去获取，如果实现了这个Aware接口，把StringValueResolver缓存起来，通过这个类去获取String类型的变量，效果是一样的。

ResourceLoaderAware

功能

用于获取ResourceLoader的一个扩展类，ResourceLoader可以用于获取classpath内所有的资源对象，可以扩展此类来拿到ResourceLoader对象。

ApplicationEventPublisherAware

功能

用于获取ApplicationEventPublisher的一个扩展类，ApplicationEventPublisher可以用来发布事件，结合ApplicationListener来共同使用，下文在介绍ApplicationListener时会详细提到。这个对象也可以通过spring注入的方式来获得。

MessageSourceAware

功能

用于获取MessageSource的一个扩展类，MessageSource主要用来做国际化。

ApplicationContextAware

功能

实现该接口可获取到 ApplicationContext，ApplicationContext应该是很多人非常熟悉的一个类了，就是spring上下文管理器，可以手动的获取任何在spring上下文注册的bean，我们经常扩展这个接口来缓存spring上下文，包装成静态方法。同时ApplicationContext也实现了BeanFactory，MessageSource，ApplicationEventPublisher等接口，也可以用来做相关接口的事情。

代码示例

1
2
3
4
5
6
7
8
@Component
public class Demo implements ApplicationContextAware {
  ApplicationContext applicationContext;
  @Override
  public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    this.applicationContext = applicationContext;
  }
}

原理

由 ApplicationContextAwareProcessor 实现，在bean对象初始化之前判断bean是否是ApplicationContextAware类型

具体方法见：postProcessBeforeInitialization

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
// org.springframework.context.support.ApplicationContextAwareProcessor
#postProcessBeforeInitialization
@Nullable
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
    AccessControlContext acc = null;
    if (System.getSecurityManager() != null && (bean instanceof EnvironmentAware || bean instanceof EmbeddedValueResolverAware || bean instanceof ResourceLoaderAware || bean instanceof ApplicationEventPublisherAware || bean instanceof MessageSourceAware || bean instanceof ApplicationContextAware)) {
        acc = this.applicationContext.getBeanFactory().getAccessControlContext();
    }
    if (acc != null) {
        AccessController.doPrivileged(() -> {
            this.invokeAwareInterfaces(bean);
            return null;
        }, acc);
    } else {
        this.invokeAwareInterfaces(bean);
    }
    return bean;
}

该方法会调用 invokeAwareInterfaces 方法注入属性。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
private void invokeAwareInterfaces(Object bean) {
    if (bean instanceof Aware) {
        if (bean instanceof EnvironmentAware) {
            ((EnvironmentAware)bean).setEnvironment(this.applicationContext.getEnvironment());
        }
        if (bean instanceof EmbeddedValueResolverAware) {
            ((EmbeddedValueResolverAware)bean).setEmbeddedValueResolver(this.embeddedValueResolver);
        }
        if (bean instanceof ResourceLoaderAware) {
            ((ResourceLoaderAware)bean).setResourceLoader(this.applicationContext);
        }
        if (bean instanceof ApplicationEventPublisherAware) {
            ((ApplicationEventPublisherAware)bean).setApplicationEventPublisher(this.applicationContext);
        }
        if (bean instanceof MessageSourceAware) {
            ((MessageSourceAware)bean).setMessageSource(this.applicationContext);
        }
        if (bean instanceof ApplicationContextAware) {
            ((ApplicationContextAware)bean).setApplicationContext(this.applicationContext);
        }
    }
}

BeanNameAware

功能

该类也是Aware扩展的一种，触发点在bean的初始化之前，也就是postProcessBeforeInitialization之前，触发点方法只有一个：setBeanName

使用场景：

用户可以扩展这个点，在初始化bean之前拿到spring容器中注册的的beanName，自行修改这个beanName的值。

代码示例

1
2
3
4
5
6
7
8
9
public class MyBeanNameAware implements BeanNameAware{
    public NormalBeanA() {
        System.out.println("MyBeanNameAware constructor");
    }
    @Override
    public void setBeanName(String name) {
        System.out.println("[MyBeanNameAware] setBeanName: " + name);
    }
}

@PostConstruct

功能

作用在bean的初始化阶段，如果对一个方法使用了@PostConstruct，会先调用这个方法。触发点是在postProcessBeforeInitialization之后，InitializingBean.afterPropertiesSet之前。

使用场景：

用户可以对某一方法进行标注，来进行初始化某一个属性

代码示例

1
2
3
4
5
6
7
8
9
public class MyPostConstruct {
    public MyPostConstruct() {
        System.out.println("[MyPostConstruct] constructor");
    }
    @PostConstruct
    public void init(){
        System.out.println("[MyPostConstruct] init");
    }
} 

InitializingBean

功能

用来初始化bean。InitializingBean接口为bean提供了初始化方法的方式，它只包括afterPropertiesSet方法，凡是继承该接口的类，在初始化bean的时候都会执行该方法。这个扩展点的触发时机在postProcessAfterInitialization之前。

使用场景：

用户实现此接口，来进行系统启动的时候一些业务指标的初始化工作。

代码示例

1
2
3
4
5
6
public class MyInitializingBean implements InitializingBean {
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("[MyInitializingBean] afterPropertiesSet");
    }
}

FactoryBean

功能

创建FactoryBean

一般情况下，Spring通过反射机制利用bean的class属性指定支线类去实例化bean，在某些情况下，实例化Bean过程比较复杂，如果按照传统的方式，则需要在bean中提供大量的配置信息。配置方式的灵活性是受限的，这时采用编码的方式可能会得到一个简单的方案。Spring为此提供了一个org.springframework.bean.factory.FactoryBean的工厂类接口，用户可以通过实现该接口定制实例化Bean的逻辑。FactoryBean接口对于Spring框架来说占用重要的地位，Spring自身就提供了70多个FactoryBean的实现。它们隐藏了实例化一些复杂bean的细节，给上层应用带来了便利。从Spring3.0开始，FactoryBean开始支持泛型，即接口声明改为FactoryBean的形式

使用场景：

用户可以扩展这个类，来为要实例化的bean作一个代理，比如为该对象的所有的方法作一个拦截，在调用前后输出一行log，模仿ProxyFactoryBean的功能。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
public class CarFactoryBean implements FactoryBean<Car> {
  @Override
  public Car getObject() throws Exception {
    return new Car();
  }
  @Override
  public Class<?> getObjectType() {
    return Car.class;
  }
  @Override
  public boolean isSingleton() {
    reutrn false; // true表示单实例
  }
}

原理

参考spring bean的加载过程，FactoryBean获取到的实际是getObject方法得到的对象，如果要获取真实的FactoryBean对象，需要在bean的id加个"&"前缀，如"&carFactoryBean"。

SmartInitializingSingleton

功能

这个接口中只有一个方法afterSingletonsInstantiated，其作用是是在spring容器管理的所有单例对象（非懒加载对象）初始化完成之后调用的回调接口。其触发时机为postProcessAfterInitialization之后。

使用场景：

用户可以扩展此接口在对所有单例对象初始化完毕后，做一些后置的业务处理。

代码示例

1
2
3
4
5
6
public class MySmartInitializingSingleton implements SmartInitializingSingleton {
    @Override
    public void afterSingletonsInstantiated() {
        System.out.println("[MySmartInitializingSingleton] afterSingletonsInstantiated ");
    }
}

CommandLineRunner

功能

接口只有一个方法：run(String... args)，触发时机为整个项目启动完毕后，自动执行。如果有多个CommandLineRunner，可以利用@Order来进行排序。

使用场景：

用户扩展此接口，进行启动项目之后一些业务的预处理。

代码示例

1
2
3
4
5
6
public class MyCommandLineRunner implements CommandLineRunner {
    @Override
    public void run(String... args) throws Exception {
        System.out.println("[MyCommandLineRunner] run ");
    }
}

DisposableBean

功能

扩展点也只有一个方法：destroy()，其触发时机为当此对象销毁时，会自动执行这个方法。比如说运行applicationContext.registerShutdownHook时，就会触发这个方法。

代码示例

1
2
3
4
5
6
public class MyDisposableBean implements DisposableBean {
    @Override
    public void destroy() throws Exception {
        System.out.println("[MyDisposableBean] destroy");
    }
}

ApplicationListener

功能

ApplicationListener可以监听某个事件的event，触发时机可以穿插在业务方法执行过程中，用户可以自定义某个业务事件。但是spring内部也有一些内置事件，可以穿插在启动调用中。可以利用这个特性，来自己做一些内置事件的监听器来达到和前面一些触发点大致相同的事情。

spring主要的内置事件：

1、ContextRefreshedEventApplicationContext

被初始化或刷新时，该事件被发布。这也可以在 ConfigurableApplicationContext接口中使用 refresh() 方法来发生。此处的初始化是指：所有的Bean被成功装载，后处理Bean被检测并激活，所有Singleton Bean 被预实例化，ApplicationContext容器已就绪可用。

2、ContextStartedEvent

使用 ConfigurableApplicationContext （ApplicationContext子接口）接口中的 start() 方法启动 ApplicationContext 时，该事件被发布。你可以调查你的数据库，或者你可以在接受到这个事件后重启任何停止的应用程序。

3、ContextStoppedEvent

使用 ConfigurableApplicationContext 接口中的 stop() 停止 ApplicationContext 时，发布这个事件。你可以在接受到这个事件后做必要的清理的工作

4、ContextClosedEvent

使用 ConfigurableApplicationContext接口中的 close()方法关闭 ApplicationContext 时，该事件被发布。一个已关闭的上下文到达生命周期末端；它不能被刷新或重启

5、RequestHandledEvent

这是一个 web-specific 事件，告诉所有 bean HTTP 请求已经被服务。只能应用于使用DispatcherServlet的Web应用。在使用Spring作为前端的MVC控制器时，当Spring处理用户请求结束后，系统会自动触发该事件

Reference

Spring启动扩展点

https://www.jianshu.com/p/397c15cbf34a

https://luyu05.github.io/2019/06/26/SpringFrame-Extension-Point/

EventListener注解的使用

5.5.2.4 - 50.Spring循环依赖

本文主要讲解Spring循环依赖的缓存及其作用

三级缓存

一级缓存

Map<String, Object> singletonObjects = new ConCurrentHashMap<>(256)

用于保存BeanName和创建bean实例之间的关系**（成品对象）**

三级缓存

Map<String, ObjectFactory> singletonFactories = new HashMap<>(16)

用于保存BeanName和创建bean的工厂之间的关系**（lambda表达式，完成代理对象的覆盖过程）**

ObjectFactory是一个函数式接口，仅有一个方法，可以传入lambda表达式，可以是匿名内部类，通过调用getObject方法来执行具体的逻辑

二级缓存

Map<String, Object> earlySingletonObjects = new ConCurrentHashMap<>(16)

保存BeanName和创建bean实例之间的关系，与singletonFactories的不同之处在于，当一个单例bean被放到这里之后，那么当bean还在就可以通过getBean方法获取到，可以方便进行循环依赖的检测**（半成品对象）**

set：可以解决

构造方法：没有办法解决

实例化和初始化分开处理，提前暴露对象

spring每次创建对象时都是先从容器中查找，找不到再创建

finishBeanFactoryInitialization(beanFactory)

beanFacatory.preInstantialteSingleton()

getBean() -> doGetBean() -> createBean() -> doCreateBean()

每次先按照顺序从一、二、三级缓存中寻找bean，当一级或二级中找到时，便移除二三级中的缓存（一级中存在时二三级都移除，二级存在时移除三级）。

问题

1、三级缓存解决循坏依赖问题的关键是什么？为什么通过提前暴露对象能解决？

实例化和初始化分开操作，在中间过中给其他对象赋值的时候，并不是一个完整对象，而是把半成品对象赋值给了其他对象

2、如果只使用一级缓存能不能解决问题？

不能。在整个处理过程中，缓存中存放的是半成品的和成品对象，如果只有一级缓存，那么成品和半成品都会放到一级缓存中，有可能在获取过程中获取到半成品对象，此时半成品对象是无法使用的，不能直接进行相关的处理，因此要把半成品和成品和成品的存放空间分割开来。

3、只使用二级缓存行不行？为什么需要三级缓存？

如果我能保证所有的bean对象都不去调用getEarlyBeanReference方法，使用二级缓存可以吗？

是的，如果保证所有的bean对象都不调用此方法，就可以只使用二级缓存！

使用三级缓存的本质在于使用AOP代理问题！！

4、如果某个bean对象代理对象，那么会不会创建普通的bean对象？

会！

5、为什么使用了三级缓存就可以解决AOP代理问题？

当一个对象需要被代理的时候，在整个过程中包含两个对象。一个是普通对象，一个是代理生成的对象，bean默认都是单例，那么我们在整个生命周期的处理环节中，一个beanname能对应两个对象吗？不能，既然不能，保证我们在使用的时候加一层判断，判断一下是否需要进行代理的处理。

6、怎么知道什么时候使用呢？

因为不知道什么时候会调用，所以通过一个匿名内部类的方式，在使用的时候直接对原对象进行覆盖操作，保证全局唯一！

7、为什么要包一层ObjectFactory对象？

如果创建的bean有对应的代理（前提），那么其他对象注入时，注入的应该是对应的代理对象；但是Spring无法提前知道这个对象是否有循环依赖的情况，而正常情况下（没有循环依赖），Spring都是在创建好完成品bean之后才创建对应的代理。这时候Spring有两个选择：

1）不管有没有循坏依赖，都提前创建好代理对象，并将代理对象放入缓存，出现循环依赖时，其他对象直接就可以取到代理对象并注入。

2）不提前创建好代理对象，在出现循坏依赖被其他对象注入时，才实时生成代理对象。这样在没有循环依赖的情况下，bean就可以按着Spring设计原则的步骤来创建。

Spring选择了第二种方式，那怎么做到提前曝光对象而又不生成代理呢？

Spring就是在对象外面包一层ObjectFactory，提前曝光的是ObjectFactory对象，在被注入时才在ObjectFactory.getObject方式内实时生成代理对象，并将生成好的代理对象放入到第二级缓存中。

为了防止对象在后面的初始化时重复代理，在创建代理时，第二级缓存会记录已代理的对象。

如果Spring选择了上面第一种方式，就会有以下不同的处理逻辑：

1、在提前曝光半成品时，直接执行getEarlyBeanReference创建到代理，并放入到二级缓存中。

2、有了上一步，就不需要通过ObjectFactory来延迟执行getEarlyBeanReference，也就不需要singletonFactory这一级缓存。

至于为什么不适用第一种方式在bean构造完之后就创建代理对象，是因为这违背了Spring的设计原则。Spring结合AOP跟bean的生命周期，是在bean创建完全之后通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的，在这个后置处理的postProcessAfterInitialization方法中对初始化后的bean完成AOP代理。如果出现了循环依赖，那没有办法，只有给bean先创建代理，但是没有出现循环依赖的情况下，设计之初就是让bean在生命周期的最后一步完成代理而不是在实例化后（未初始化）就立马完成代理。

构造器依赖注入

解决方法及原理探索，参考：https://www.jianshu.com/p/a178d84d2bcb

使用@lazy注解，代理。

构造器注入源码分析，参考：https://cloud.tencent.com/developer/article/1461797

https://www.jianshu.com/p/885c2389b0e4

Reference

Spring循环依赖是否可以去掉第三层缓存

5.5.2.5 - 51.SpringBean的加载源码

本文主要讲解Spring Bean的加载

Spring源码阅读技巧

1、Spring源码中真正干活的都是以do开头的方法

2、只找有正确返回结果的代码

3、条件断点

4、发挥想象分析、猜

测试代码

resources/applicationContext.xml

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="taxCalDTO" class="com.chnherb.cg.rebate.service.dto.common.TaxCalDTO">
        <property name="currency_code" value="USD"/>
    </bean>
</beans>

BeanTest.java

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
package com.chnherb.cg;
import com.chnherb.cg.rebate.service.dto.common.TaxCalDTO;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class BeanTest {
    public static void main(String[] args) {
        ApplicationContext ac = new FileSystemXmlApplicationContext("classpath:applicationContext.xml");
        ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationContext.xml");
        TaxCalDTO taxCalDTO = (TaxCalDTO) context.getBean("taxCalDTO");
        System.out.println(taxCalDTO);
    }
}

Bean的加载

参考Spring源码书P79

整体流程图

bean的获取

1
2
3
4
5
6
7
8
@Override
public Object getBean(String name) throws BeansException {
   return doGetBean(name, null, null, false);
}
@Override
public <T> T getBean(String name, Class<T> requiredType) throws BeansException {
   return doGetBean(name, requiredType, null, false);
}

获取bean的bean的过程：

1、转换对应的beanName

传入的参数name不一定是beanName，可能是别名，也可能是FactoryBean，需要进一步转换

1
final String beanName = transformedBeanName(name);

去除FactoryBean的修饰符，也就是如果name="&aa"，那么首先去除&而使name="aa"
将别名alias转成最终的beanName

2、尝试从缓存中加载单例

单例在同一个容器中只会创建一次，先尝试加载单例，如果加载不成功则再次尝试从singletonFactories中加载。

1
2
3
4
// 尝试从缓存获取 或 singletonFactories中的ObjectFactory中获取
Object sharedInstance = getSingleton(beanName);
// 存在如BeanFactory的情况并不是直接返回实例本身，而是返回指定方法返回的实例
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);

因为在创建单例bean的时候会存在依赖注入的情况，而在创建依赖的时候为了避免循环依赖，在Spring中创建bean的原则是不等bean创建完成就会将创建bean的ObjectFactory提早曝光加入到缓存中，一旦下一个bean创建时候需要依赖上一个bean则直接使用ObjectFactory（详细见循环依赖）

3、bean的实例化

如果从缓存中得到了bean的原始状态，则需要对bean进行实例化。

强调：缓存中只是原始的bean状态，不一定是最终想要的bean。如需要对工厂bean进行处理，那么这里得到的其实是工厂bean的初始状态，但我们真正需要的是工厂bean中定义的factory-method方法中返回的bean，而getObjectBeanInstance就是完成这个工作的

4、原型模式的依赖检查

只有在单例的情况下才会尝试解决循坏依赖

1
2
3
if (isPrototypeCurrentlyInCreation(beanName)) {
   throw new BeanCurrentlyInCreationException(beanName);
}

5、检测parentBeanFactory

!containsBeanDefinition检测如果当前加载的XML配置文件中不包含beanName所对应的配置，就只能到parentBeanFactory尝试下，然后递归地调用getBean方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
// Check if bean definition exists in this factory.
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
   // Not found -> check parent.
   String nameToLookup = originalBeanName(name);
   if (args != null) {
      // Delegation to parent with explicit args.
      return (T) parentBeanFactory.getBean(nameToLookup, args);
   }
   else {
      // No args -> delegate to standard getBean method.
      return parentBeanFactory.getBean(nameToLookup, requiredType);
   }
}

6、转换Definition

将存储XML配置文件的GernericBeanDifinition转换为RootBeanDifinition。

因为从XML配置文件中读取到的Bean信息是存储在GernericBeanDifinition中的，但是所有的Bean后续处理都是针对于RootBeanDefinition的，所以需要进行转换。转换的同时如果父类bean不为空的话，则会一并合并父类的属性。

1
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);

7、寻找依赖

因为bean的初始化过程中很可能会用到某些属性，某些属性很可能是动态配置的，并且配置成依赖于其他的bean，那么这个时候有必要先加载依赖的bean。

1
String[] dependsOn = mbd.getDependsOn();

8、针对不同的scope进行bean的创建

Spring默认的scope是singleton，其他如prototype、request。该步骤根据不同的配置进行不同的初始化策略。

1
2
String scopeName = mbd.getScope();
final Scope scope = this.scopes.get(scopeName);

9、类型转换

该功能是将返回的bean转换为requiredType指定的类型。如将String转换成Integer，或者其他的转换器。用户也可以自己扩展转换器。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// Check if required type matches the type of the actual bean instance.
if (requiredType != null && bean != null && !requiredType.isAssignableFrom(bean.getClass())) {
   try {
      return getTypeConverter().convertIfNecessary(bean, requiredType);
   }
   catch (TypeMismatchException ex) {
      if (logger.isDebugEnabled()) {
         logger.debug("Failed to convert bean '" + name + "' to required type [" +
               ClassUtils.getQualifiedName(requiredType) + "]", ex);
      }
      throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
   }
}

1、FactoryBean的使用

FactoryBean接口对于Spring框架来说占有重要的地位，Spring自身提供了70多个FactoryBean的实现。它们隐藏了实例化一些复杂的bean的细节，给上层应用带来了便利。

当配置文件中的class属性配置的实现类是FactoryBean时，通过getBean()方法返回的不是FactoryBean本身，而是FactoryBean#getObject()方法所返回的对象，相当于FactoryBean#getObject()代理了getBean()方法。

举个例子，使用逗号分隔将多个属性值配置在一个参数中，这种自定义的配置方式比较灵活。详细可见P84。

如果需要获取到XXFactoryBean的实例，则需要在使用getBean(beanName)方法时在beanName前显式地加上"&"前缀，例如getBean("&car")

2、缓存中获取单例bean

因为在创建单例bean的过程中会存在依赖注入的情况，而在创建依赖的时候为了避免循坏依赖，Spring创建bean的原则是不等bean创建完成就会将创建bean的ObjectFactory提早曝光加入到缓存中，一旦下一个bean创建时需要依赖上个bean，则直接使用ObjectFactory。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
@Override
public Object getSingleton(String beanName) {
   // 参数true设置标识允许早期依赖
   return getSingleton(beanName, true);
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
   // 检查缓存中是否存在实例
   Object singletonObject = this.singletonObjects.get(beanName);
   if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
      // 如果为空，则锁定全局变量并进行处理
      synchronized (this.singletonObjects) {
         // 如果此bean正在加载则不处理
         singletonObject = this.earlySingletonObjects.get(beanName);
         if (singletonObject == null && allowEarlyReference) {
            // 某些方法需要提前初始化则会调用addSingletonFactory方法将对应的ObjectFactory初始化策略存储在singletonFactories
            ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
            if (singletonFactory != null) {
               // 调用预先设定的getObject方法
               singletonObject = singletonFactory.getObject();
               // 记录在缓存中，earlySingletonObjects和singletonFactories互斥
               this.earlySingletonObjects.put(beanName, singletonObject);
               this.singletonFactories.remove(beanName);
            }
         }
      }
   }
   return (singletonObject != NULL_OBJECT ? singletonObject : null);
}

简单解释存储bean的不同map 1、singletonObjects：用于保存BeanName和创建bean实例之间的关系，bean name -> bean instance

2、singletonFactories：用于保存BeanName和创建bean的工厂之间的关系，bean name -> ObjectFactory

3、earlySingletonObjects：也是保存beanName和创建bean实例之间的关系，只不过这里的bean相当于半成品，其目的是用来检测循环引用。

4、registeredSingletons：用来保存当前所有已注册的bean。

3、从bean的实例中获取对象

在getBean方法中，getObjectForBeanInstance是个高频使用的方法，无论是从缓存中获得bean还是根据不同的scope策略加载bean，总之我们得到bean的实例后要做的第一步就是调用该方法检测正确性，其实就是用于检测当前bean是否是FactoryBean类型的bean，如果是，则调用该bean对应FactoryBean实例中的getObject()作为返回值。

无论是从缓存中获取到的bean还是通过不同的scope策略加载的bean都只是最原始的bean状态，并不一定是我们最终想要的bean。举个例子，假如我们需要对工厂bean进行处理，那么这里得到的其实是工厂bean的初始状态，但是我们真正需要的是工厂bean中定义的factory-method方法中返回的bean，而getObjectForBeanInstance方法就是完成这个工作的。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
protected Object getObjectForBeanInstance(
      Object beanInstance, String name, String beanName, RootBeanDefinition mbd) {
   // 如果指定的name是工厂相关(以&为前缀)且beanInstance又不是FactoryBean类型则验证不通过
   if (BeanFactoryUtils.isFactoryDereference(name) && !(beanInstance instanceof FactoryBean)) {
      throw new BeanIsNotAFactoryException(transformedBeanName(name), beanInstance.getClass());
   }
   // 实例可能是正常的bean也可能是FactoryBean
   // 如果是FactoryBean，如果用户想要直接获取工厂实例而不是工厂对应的getObject方法对应的实例那么传入的name应该加入前缀&
   if (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils.isFactoryDereference(name)) {
      return beanInstance;
   }
   // 加载FactoryBean
   Object object = null;
   if (mbd == null) {
      // 尝试从缓存中加载bean
      object = getCachedObjectForFactoryBean(beanName);
   }
   if (object == null) {
      // 到这里已经明确知道beanInstance一定是FactoryBean实例
      FactoryBean<?> factory = (FactoryBean<?>) beanInstance;
      // containsBeanDefinition检测beanDefinitionMap中也就是在所有已经加载的类中检测是否定义beanName
      if (mbd == null && containsBeanDefinition(beanName)) {
         // 将存储XML配置文件中的GernericBeanDefinition转换为RootBeanDefinition，如果指定BeanName是子Bean的话同时会合并父类的相关属性
         mbd = getMergedLocalBeanDefinition(beanName);
      }
      // 是否是用户定义的而不是应用程序本身定义的
      boolean synthetic = (mbd != null && mbd.isSynthetic());
      // 真正核心的代码
      object = getObjectFromFactoryBean(factory, beanName, !synthetic);
   }
   return object;
}

上述代码大多是辅助代码以及一些功能性的判断，真正的核心代码委托给了getObjectFromFactoryBean。上述代码主要的工作：

1）对FactoryBean正确性的验证

2）对非FactoryBean不做任何处理

3）对bean进行转换

4）将从Factory中解析bean的工作委托给getObjectFromFactoryBean

getObjectFromFactoryBean方法只做了一件事，即返回的bean如果是单例的，就必须保证全局唯一，同时，如果是单例，不必重复创建，可以使用缓存来提高性能。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {
   if (factory.isSingleton() && containsSingleton(beanName)) {
      synchronized (getSingletonMutex()) {
         Object object = this.factoryBeanObjectCache.get(beanName);
         if (object == null) {
            object = doGetObjectFromFactoryBean(factory, beanName);
            // Only post-process and store if not put there already during getObject() call above
            // (e.g. because of circular reference processing triggered by custom getBean calls)
            Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
            if (alreadyThere != null) {
               object = alreadyThere;
            }
            else {
               if (object != null && shouldPostProcess) {
                  try {
                     // 调用后置处理器
                     object = postProcessObjectFromFactoryBean(object, beanName);
                  }
                  catch (Throwable ex) {
                     throw new BeanCreationException(beanName,
                           "Post-processing of FactoryBean's singleton object failed", ex);
                  }
               }
               this.factoryBeanObjectCache.put(beanName, (object != null ? object : NULL_OBJECT));
            }
         }
         return (object != NULL_OBJECT ? object : null);
      }
   }
   else {
      Object object = doGetObjectFromFactoryBean(factory, beanName);
      if (object != null && shouldPostProcess) {
         try {
            // 调用后置处理器
            object = postProcessObjectFromFactoryBean(object, beanName);
         }
         catch (Throwable ex) {
            throw new BeanCreationException(beanName, "Post-processing of FactoryBean's object failed", ex);
         }
      }
      return object;
   }
}

注意后置处理代码在不同的spring版本中位置不一样，有的放在getObjectFromFactoryBean中，有的放在doGetObjectFromFactoryBean中

doGetObjectFromFactoryBean方法中就是最终的方法，即factory.getObject()。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
private Object doGetObjectFromFactoryBean(final FactoryBean<?> factory, final String beanName)
      throws BeanCreationException {
   Object object;
   try {
      // 需要权限验证
      if (System.getSecurityManager() != null) {
         AccessControlContext acc = getAccessControlContext();
         try {
            object = AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
               @Override
               public Object run() throws Exception {
                     return factory.getObject();
                  }
               }, acc);
         }
         catch (PrivilegedActionException pae) {
            throw pae.getException();
         }
      }
      else {
         // 直接调用getObject方法
         object = factory.getObject();
      }
   }
   catch (FactoryBeanNotInitializedException ex) {
      throw new BeanCurrentlyInCreationException(beanName, ex.toString());
   }
   catch (Throwable ex) {
      throw new BeanCreationException(beanName, "FactoryBean threw exception on object creation", ex);
   }
   // Do not accept a null value for a FactoryBean that's not fully
   // initialized yet: Many FactoryBeans just return null then.
   if (object == null && isSingletonCurrentlyInCreation(beanName)) {
      throw new BeanCurrentlyInCreationException(
            beanName, "FactoryBean which is currently in creation returned null from getObject");
   }
   return object;
}

可以看到获取到bean之后，没有立即返回，而是接下来又进行了后处理的操作postProcessObjectFromFactoryBean 后处理规则：尽可能保证所有bean初始化后都会调用注册的BeanPostProcessor的postProcessAfterInitialization方法进行处理，在实际开发过程中大可以针对此特性设计自己的业务逻辑。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
      throws BeansException {
   Object result = existingBean;
   for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) {
      result = beanProcessor.postProcessAfterInitialization(result, beanName);
      if (result == null) {
         return result;
      }
   }
   return result;
}

注意：这里找代码涉及到子类方法的覆盖

4、获取单例

如果缓存中不存在已经加载过的单例bean就需要从头开始bean的加载过程了，而spring中使用getSingleton的重载方法实现bean的加载过程。

调用入口：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
   @Override
   public Object getObject() throws BeansException {
      try {
         return createBean(beanName, mbd, args);
      }
      catch (BeansException ex) {
         // Explicitly remove instance from singleton cache: It might have been put there
         // eagerly by the creation process, to allow for circular reference resolution.
         // Also remove any beans that received a temporary reference to the bean.
         destroySingleton(beanName);
         throw ex;
      }
   }
});

getSingleton重载方法

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
   Assert.notNull(beanName, "'beanName' must not be null");
   // 全局变量需要同步  
   synchronized (this.singletonObjects) {
      // 首先检查对应的bean是否已经加载过，因为singleton模式其实就是复用以创建的bean
      Object singletonObject = this.singletonObjects.get(beanName);
      // 如果为空才可以进行singleto的bean的初始化
      if (singletonObject == null) {
         if (this.singletonsCurrentlyInDestruction) {
            throw new BeanCreationNotAllowedException(beanName,
                  "Singleton bean creation not allowed while the singletons of this factory are in destruction " +
                  "(Do not request a bean from a BeanFactory in a destroy method implementation!)");
         }
         if (logger.isDebugEnabled()) {
            logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
         }
         // 前处理
         beforeSingletonCreation(beanName);
         boolean newSingleton = false;
         boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
         if (recordSuppressedExceptions) {
            this.suppressedExceptions = new LinkedHashSet<Exception>();
         }
         try {
            // 初始化bean
            singletonObject = singletonFactory.getObject();
            newSingleton = true;
         }
         catch (IllegalStateException ex) {
            // Has the singleton object implicitly appeared in the meantime ->
            // if yes, proceed with it since the exception indicates that state.
            singletonObject = this.singletonObjects.get(beanName);
            if (singletonObject == null) {
               throw ex;
            }
         }
         catch (BeanCreationException ex) {
            if (recordSuppressedExceptions) {
               for (Exception suppressedException : this.suppressedExceptions) {
                  ex.addRelatedCause(suppressedException);
               }
            }
            throw ex;
         }
         finally {
            if (recordSuppressedExceptions) {
               this.suppressedExceptions = null;
            }
            // 后处理
            afterSingletonCreation(beanName);
         }
         if (newSingleton) {
            // 加入缓存
            addSingleton(beanName, singletonObject);
         }
      }
      return (singletonObject != NULL_OBJECT ? singletonObject : null);
   }
}

上述代码使用了回调方法，使得程序可以在单例创建的前后做一些准备及处理操作，而真正的获取单例bean的方法其实并不是在此方法中实现的，其实现逻辑是在ObjectFactory类型的实例singletonFactory中实现的。而这些准备及处理操作包括如下内容： 1）检查缓存是否已经加载过

2）若没有加载，则记录beanName的正在加载状态

3）加载单例前记录状态

beforeSingletonCreation不是空实现，做了很重要的操作：记录加载状态，即通过singletonsCurrentlyInCreation.add(beanName)将当前正要创建的bean记录在缓存中，这样便可以对循环依赖进行检测。

1
2
3
4
5
protected void beforeSingletonCreation(String beanName) {
   if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
      throw new BeanCurrentlyInCreationException(beanName);
   }
}

4）通过调用参数传入的ObjectFactory的个体Object方法实例化bean 5）加载单例后的处理方法调用

与步骤3）相似，当bean加载结束后需要移除缓存中对该bean的正在加载状态的记录

6）将结果记录至缓存并删除加载bean过程中所记录的各种辅助状态

1
2
3
4
5
6
7
8
protected void addSingleton(String beanName, Object singletonObject) {
   synchronized (this.singletonObjects) {
      this.singletonObjects.put(beanName, (singletonObject != null ? singletonObject : NULL_OBJECT));
      this.singletonFactories.remove(beanName);
      this.earlySingletonObjects.remove(beanName);
      this.registeredSingletons.add(beanName);
   }
}

7）返回处理结果代码见上面的获取单例的调用入口getSingleton

5、准备创建bean

即上述getSingleton中调用createBean方法

注意源码溯源方法的重载覆盖

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
@Override
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
   if (logger.isDebugEnabled()) {
      logger.debug("Creating instance of bean '" + beanName + "'");
   }
   RootBeanDefinition mbdToUse = mbd;
   // 锁定class，根据设置的class属性或者className来解析Class
   Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
   if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
      mbdToUse = new RootBeanDefinition(mbd);
      mbdToUse.setBeanClass(resolvedClass);
   }
   // 验证及准备覆盖的方法
   try {
      mbdToUse.prepareMethodOverrides();
   }
   catch (BeanDefinitionValidationException ex) {
      throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
            beanName, "Validation of method overrides failed", ex);
   }
   try {
      // 给BeanPostProcessors一个机会来返回代理替代真正的实例
      Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
      if (bean != null) {
         return bean;
      }
   }
   catch (Throwable ex) {
      throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
            "BeanPostProcessor before instantiation of bean failed", ex);
   }
   Object beanInstance = doCreateBean(beanName, mbdToUse, args);
   if (logger.isDebugEnabled()) {
      logger.debug("Finished creating instance of bean '" + beanName + "'");
   }
   return beanInstance;
}

处理override属性

1
mbdToUse.prepareMethodOverrides();

实例化的前置处理

当经过前置处理后返回的结如果不为空，那么会直接略过后序的Bean的创建而直接返回结果。这一特性起着至关重要的作用，AOP功能是基于这里判断的

1
resolveBeforeInstantiation

6、循环依赖

7、创建bean

createBean调用核心代码doCreateBean

整个函数的概要思路：

1）如果是单例需要首先清楚缓存

2）实例化bean，将BeanDefinition转换为BeanWrapper

3）MergedBeanDefinitionPostProcessor的应用

bean合并后的处理，Autowired注解正是通过此方法实现诸如类型的预解析

4）依赖处理

5）属性填充

6）循环依赖处理

7）注册DisposableBean

如果配置了destroy-method，需要注册以便于在销毁时候调用

8）完成创建并返回

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
   // Instantiate the bean.
   BeanWrapper instanceWrapper = null;
   if (mbd.isSingleton()) {
      instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
   }
   if (instanceWrapper == null) {
      // 根据指定bean使用对应的策略创建新的实例，如：工厂方法、构造函数自动注入、简单初始化
      instanceWrapper = createBeanInstance(beanName, mbd, args);
   }
   final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
   Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
   // Allow post-processors to modify the merged bean definition.
   synchronized (mbd.postProcessingLock) {
      if (!mbd.postProcessed) {
         // 应用MergedBeanDefinitionPostProcessor
         applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
         mbd.postProcessed = true;
      }
   }
   // 是否需要提早曝光：单例&允许循环依赖&当前bean正在创建中，检测循环依赖
   boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
         isSingletonCurrentlyInCreation(beanName));
   if (earlySingletonExposure) {
      if (logger.isDebugEnabled()) {
         logger.debug("Eagerly caching bean '" + beanName +
               "' to allow for resolving potential circular references");
      }
      // 为避免后期循环依赖，可以在bean初始化完成前将创建实例的ObjectFactory工厂
      addSingletonFactory(beanName, new ObjectFactory<Object>() {
         @Override
         public Object getObject() throws BeansException {
            // 对bean再一次循环依赖，主要应用SmartInstantiationAware BeanPostProcessor
            // 其中我们熟悉的AOP就是在这里将advice动态织入bean中，若没有则直接返回bean，不做处理
            return getEarlyBeanReference(beanName, mbd, bean);
         }
      });
   }
   // Initialize the bean instance.
   Object exposedObject = bean;
   try {
      // 对bean进行填充，将各个属性值织入，其中，可能存在依赖于其他bean的属性，则会递归初始依赖bean
      populateBean(beanName, mbd, instanceWrapper);
      if (exposedObject != null) {
         // 调用初始化方法，比如init-method
         exposedObject = initializeBean(beanName, exposedObject, mbd);
      }
   }
   catch (Throwable ex) {
      if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
         throw (BeanCreationException) ex;
      }
      else {
         throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
      }
   }
   if (earlySingletonExposure) {
      Object earlySingletonReference = getSingleton(beanName, false);
      // 只有在检测到有循环依赖的情况下才会不为空
      if (earlySingletonReference != null) {
         // 如果exposedObject没有在初始化方法中被改变，也就是没有被增强
         if (exposedObject == bean) {
            exposedObject = earlySingletonReference;
         }
         else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
            String[] dependentBeans = getDependentBeans(beanName);
            Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
            for (String dependentBean : dependentBeans) {
               // 检测依赖
               if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
                  actualDependentBeans.add(dependentBean);
               }
            }
            // 因为bean创建后其所依赖的bean一定是已经创建的
            // actualDependentBeans不为空则表示当前bean创建后其依赖的bean却没有没全部创建，也就是说存在循环依赖
            if (!actualDependentBeans.isEmpty()) {
               throw new BeanCurrentlyInCreationException(beanName,
                     "Bean with name '" + beanName + "' has been injected into other beans [" +
                     StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
                     "] in its raw version as part of a circular reference, but has eventually been " +
                     "wrapped. This means that said other beans do not use the final version of the " +
                     "bean. This is often the result of over-eager type matching - consider using " +
                     "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
            }
         }
      }
   }
   // Register bean as disposable.
   try {
      // 根据scope注册bean
      registerDisposableBeanIfNecessary(beanName, bean, mbd);
   }
   catch (BeanDefinitionValidationException ex) {
      throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
   }
   return exposedObject;
}

创建bean的实例

实例化逻辑：

1）如果在RootBeanDefinition中存在factoryMethodName属性，或者在配置文件中配置了factory-method，那么Spring会尝试使用instantiateUsingFactoryMethod(beanName, mbd, args)方法根据RootBeanDefinition中的配置生成bean的实例

2）解析构造函数并进行构造函数的实例化。因为一个bean对应的类中可能会有多个构造函数，而每个构造函数的参数不同，Spring在根据参数及类型去判断最终会使用哪个构造函数进行实例化。但是，判断的过程是个比较消耗性能的步骤，所以采用缓存机制，如果已经解析过则不需要重复解析而是直接从RootBeanDefinition中的属性resolvedConstructorOrFacrotyMethod缓存的值去取，否则需要再次解析，并将解析的结果添加至RootBeanDefinition中的属性resolvedConstructorOrFactoryMethod中。

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
   // 解析class
   Class<?> beanClass = resolveBeanClass(mbd, beanName);
   if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
      throw new BeanCreationException(mbd.getResourceDescription(), beanName,
            "Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
   }
   // 如果工厂方法不为空则使用工厂方法初始化策略
   if (mbd.getFactoryMethodName() != null)  {
      return instantiateUsingFactoryMethod(beanName, mbd, args);
   }
   // Shortcut when re-creating the same bean...
   boolean resolved = false;
   boolean autowireNecessary = false;
   if (args == null) {
      synchronized (mbd.constructorArgumentLock) {
         // 一个类有多个构造函数，每个构造函数都有不同的参数，所以调用前需要先根据参数锁定构造函数或对应的工厂方法
         if (mbd.resolvedConstructorOrFactoryMethod != null) {
            resolved = true;
            autowireNecessary = mbd.constructorArgumentsResolved;
         }
      }
   }
   // 如果已经解析过则使用解析好的构造函数方法不需要再次锁定
   if (resolved) {
      if (autowireNecessary) {
         // 构造函数自动注入
         return autowireConstructor(beanName, mbd, null, null);
      }
      else {
         // 使用默认构造函数构造
         return instantiateBean(beanName, mbd);
      }
   }
   // 需要根据参数解析构造函数
   Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
   if (ctors != null ||
         mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
         mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
      // 构造函数自动注入
      return autowireConstructor(beanName, mbd, ctors, args);
   }
   // 使用默认构造函数构造
   return instantiateBean(beanName, mbd);
}

1、autowireConstructor

对于实例的创建Spring分成了两种情况，一种是通用的实例化，另一种是带有参数的实例化。带有参数的实例化过程相当复杂，因为存在着不确定性，所以在判断对应参数上做了大量工作。

这里代码逻辑太长，略，见P105

1）构造函数参数的确定

根据explicitArgs参数判断
缓存中获取
配置文件中获取 2）构造函数的确定

3）根据确定的构造函数转换对应的参数类型

4）构造函数不确定性的验证

5）根据实例化策略以及得到的构造函数及构造函数参数实例化Bean。

2、instantiateBean

不带参数的构造函数的实例化过程

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
   try {
      Object beanInstance;
      final BeanFactory parent = this;
      if (System.getSecurityManager() != null) {
         beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {
            @Override
            public Object run() {
               return getInstantiationStrategy().instantiate(mbd, beanName, parent);
            }
         }, getAccessControlContext());
      }
      else {
         beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
      }
      BeanWrapper bw = new BeanWrapperImpl(beanInstance);
      initBeanWrapper(bw);
      return bw;
   }
   catch (Throwable ex) {
      throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
   }
}

3、实例化策略

经过前面的分析，已经得到了足以实例化的所有相关信息，完全可以使用最简单的反射方法直接反射来构造实例对象，但Spring却没有这么做

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {
   // 如果有需要覆盖或者动态替换的方法则当然需要使用cglib进行动态代理，因为可以再创建代理的同时将动态方法织入类中
   // 但是如果没有需要动态改变的方法，为了方便直接反射就可以了
   if (bd.getMethodOverrides().isEmpty()) {
      Constructor<?> constructorToUse;
      synchronized (bd.constructorArgumentLock) {
         constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
         if (constructorToUse == null) {
            final Class<?> clazz = bd.getBeanClass();
            if (clazz.isInterface()) {
               throw new BeanInstantiationException(clazz, "Specified class is an interface");
            }
            try {
               if (System.getSecurityManager() != null) {
                  constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {
                     @Override
                     public Constructor<?> run() throws Exception {
                        return clazz.getDeclaredConstructor((Class[]) null);
                     }
                  });
               }
               else {
                  constructorToUse = clazz.getDeclaredConstructor((Class[]) null);
               }
               bd.resolvedConstructorOrFactoryMethod = constructorToUse;
            }
            catch (Exception ex) {
               throw new BeanInstantiationException(clazz, "No default constructor found", ex);
            }
         }
      }
      return BeanUtils.instantiateClass(constructorToUse);
   }
   else {
      // Must generate CGLIB subclass.
      return instantiateWithMethodInjection(bd, beanName, owner);
   }
}

首先判断如果beanDefinition.getMethodOverrides()为空也就是用户没有使用replace或lookup的配置方法，那么直接使用反射的方式，简单快捷，但是如果使用了这两个特性，就直接使用反射的方式创建实例就不妥了，因为需要将这两个配置提供的功能切入进去，所以就必须使用动态代理的方式将包含两个特性对应的逻辑的拦截增强设置进去，这样百能保证在调用方法的时候会被相应的拦截器增强，返回值为包含拦截器的代理实例。

记录创建bean的ObjectFactory

在doCreate函数中有这样一段代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
      isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
   if (logger.isDebugEnabled()) {
      logger.debug("Eagerly caching bean '" + beanName +
            "' to allow for resolving potential circular references");
   }
   // 为避免后期循环依赖，可以在bean初始化完成前将创建实例的ObjectFactory加入工厂
   addSingletonFactory(beanName, new ObjectFactory<Object>() {
      @Override
      public Object getObject() throws BeansException {
         // 对bean再一次依赖引用，主要应用SmartInstantiationAware BeanPostProcessor
         // 其中我们熟知的AOP就是在这里将advice动态织入bean中，若没有则直接返回bean，不做任何处理
         return getEarlyBeanReference(beanName, mbd, bean);
      }
   });
}

属性注入

1
populateBean

autowireByName

autowireByType

autowireByType与autowireByName对于我们理解与使用来说复杂程度都很相似，但是其实现功能的复杂度却完全不一样。

applyPropertyValues

初始化bean

1
initalizeBean

注册DisposableBean

除了熟知的配置属性destroy-method方法外，用户还可以注册后处理器DestructionAwareBeanPostProcessor来统一处理bean的销毁方法

容器的功能扩展

BeanFactory接口以及它的默认实现类XmlBeanFactory，Spring还提供了另一个接口ApplicationContext，用于扩展BeanFactory的现有功能。

ApplicationContext和BeanFactory都是用于加载bean的，相比之下，ApplicationContext提供了更多的扩展功能，包含BeanFactory的所有功能，通常建议比BeanFactory优先（除非在一些限制的场合，如字节长度对内存有很大的影响时(Applet)）。

1
2
3
4
// 使用BeanFactory方式加载xml
BeanFactory bf = new XmlBeanFactory(new ClassPathResource("beanFacotryTest.xml"));
// 使用ApplicationContext方式加载xml
ApplicationContext bf = new ClassPathXmlApplicationContext("beanFactoryText.xml");

Spring的扩展

prepareRefresh

iniPropertySources()

留给子类覆盖，初始化属性资源

getEnvironment().validateRequiredProperties()

创建并获取环境对象，验证需要的属性文件是否都已经放入环境中

obtainFreshBeanFactory

加载xml配置文件的属性值到当前工厂中，最重要的就是BeanDefinition

扩展实现customizeBeanFactory方法

此方法是用来实现BeanFactory的属性设置，主要是设置两个属性：

allowBeanDefinitionOverriding：是否允许覆盖同名称的不同定义的对象

allowCircularReferences：是否允许bean之间的循环依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class MyClassPathXmlApplicationContext extends ClassPathXmlApplicationContext {
  MyClassPathXmlApplicationContext(String... locations) {
  super(location);
}
  @Override
  protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
    super.setAllowBeanDefinitionOverriding(true);
    super.setAllowCircularReference(true);
    super.customizeBeanFactory(beanFactory);
  }
}

适配器模式

debug时调用toString()方法初始化加载文件

xml配置文件头信息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
        ">
    <!-- 示意
    <context:property-placeholder location="classpath:spring-mvc.xml"></context:property-placeholder>
    -->
    <bean id="user" class="com.huangbo.pojo.User">
        <property name="name" value="zhangsan"/>
    </bean>
</beans>

bean覆盖问题

https://blog.csdn.net/f641385712/article/details/93777536

5.5.2.6 - spring注解驱动+源码

组件注册

给容器中注入组件

1）包扫描+组件标注注解

（@Controller/@Service/@Repository/@Component）

2）@Bean导入

[导入的第三方包里面的组件]

3）@Import

[快速给容器中导入一个组件]，查看源码，可以看到有三种导入方法

3.1）@Import

(要导入到容器中的组件)：容器找那个就会自动注册这个组件，id默认是全类名

3.2）ImportSelector

返回需要导入的全类名数组(注意：可以返回空数组，但不要返回null)

3.3）ImportBeanDefinitionRegistrar

注：在Config的类上注，如下

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
@Import({Color.class,Red.class, MyImportSelector.class, MyImportBeanDefinitionRegistrar})
//@Import(Color.class)
@Configuration
public class Config{
    @Lazy
    @Bean("person")
    public Person person() {
        return new Person();
    }
}

public class MyImportSelector implements ImportSelector {
    // 返回值，就是要导入到容器中的组件全类名
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        // 不要返回null
        return new String[]{"com.xxx.xxx.Yellow","com.xxx.xxx.Blue"}
    }
}

public class MyImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {
    // AnnotationMetadata: 当前类的注解信息
    // BeanDefinitionRegistry: BeanDefinition注册类，把所有需要添加到容器中的类注册进去.
    // 调用BeanDefinitionRegistry.registerBeanDefinition手工注册
    @Override
    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry beanDefinitionRegistry) {
        boolean definition = registry.containBeanDefinition("red");
        if (definition) {
            
        }
    }
}

4）使用FactoryBean（工厂Bean）

4.1）默认获取到的是工厂bean调用getObject创建的对象

4.2）要获取工厂Bean本身，需要在id前面加一个&（查看FactoryBean接口源码，定义了常量）

Expand/Collapse Code Block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public class ColorFactoryBean implements FactoryBean<Color> {
    // 返回一个对象，该对象会添加到容器中
    @Override
    public Color getObject() throws Exception {
        return new Color();
    }
    @Override
    public Class<?> getObjectType() {
        return Color.class;
    }
    // ture：容器中只保留一份
    // false: 多份
    @Override
    public boolean isSingleton() {
        reutrn false;
    }
}

@Configuration
public class Config{
    @Bean
    public ColorFactoryBean colorFactoryBean() {
        return new ColorFactoryBean();
    }
}

生命周期

指定初始化和销毁方法

1、指定初始化方法和销毁方法

1
2
3
4
5
6
7
8
9
@ComponentSan("com.xxx.bean")
@Configuration
public class MainConfigOfLifeCycle {
    // 指定car中定义的方法
    @Bean(initMethod="init", destroyMethod="destroy")
    public Car car() {
        returen new Car();
    }
}

2、通过让Bean实现InitializingBean（定义初始化逻辑）、DisposableBean（定义销毁逻辑） 3、可以使用JSR250，在bean定义的方法上加上以下注解 @PostConstruct：bean创建完成 @PreDestroy：容易移除bean之前

4、BeanPostProcessor接口，bean的后置处理器；在bean初始化前后进行一些处理工作； postProcessBeforeInitialization(Object object, xxx); postProcessAfterInittialization(Object object, xxx);

InstantiationAwareBeanPostProcessor

其方法postProcessAfterInstantiation，可以根本Object bean判断需要实例话的方法，或者全部不实例化

AOP

@EnableAspectJAutoProxy

1、@Import(AspectJAutoProxyRegistrar.class 给容器中导入AspectJAutoProxyRegistrar，

利用AspectJAutoProxyRegistrar自定义给容器中注册bean。

internalAutoProxyCreator = AnnotationAwareAspectJAutoProxyCreator

给容器中注册一个AnnotationAwareAspectJAutoProxyCreator

2、AnnotationAwareAspectJAutoProxyCreator

类的继承关系

1
2
3
4
5
6
AnnotationAwareAspectJAutoProxyCreator
  ->AspectJAwareAdvisorAutoProxyCreator
    ->AbstractAdvisorAutoProxyCreator
      ->AbstractAutoProxyCreator
      impl SmartInstantiationAwareBeanPostProcessor, BeanFactoryAware
      //关注后置处理器、自动装配bean

类的主要方法

1
2
3
4
5
6
AbstractAutoProxyCreator.setBeanFactory()
AbstractAutoProxyCreator.后置处理器逻辑

AbstractAdvisorAutoProxyCreator.setBeanFactory()->initBeanFactory()

AnnotationAwareAspectJAutoProxyCreator.initBeanFactory()

调用流程

1、传入配置类，创建ioc容器

2、注册配置类，调用refresh()刷新容器

3、registerBeanPostProcessors(beanFactory);注册bean的后置处理器来拦截bean的创建

3.1、先获取ioc容器已经定义了的需要创建对象的所有BeanPostProcessor

3.2、给容器中加别的BeanPostProcessor

3.3、优先注册实现了PriorityOrdered接口的BeanPostProcessor

3.4、再给容器中注册实现了Ordered接口的BeanPostProcessor

3.5、没实现优先级接口的BeanPostProcessor

3.6、注册BeanPostProcessor，实际上就是创建BeanPostProcessor对象，保存在容器中。

创建internalAutoProxyCreator的BeanPostProcessor【AnnotationAwareAspectJAutoProxyCreator】

3.6.1、创建bean的实例

3.6.2、populateBean：给bean各种属性赋值

3.6.3、initializeBean：初始化bean

3.6.3.1、invokeAwareMethods()：处理Aware接口的方法回调

3.6.3.2、applyBeanPostProcessorsBeforeInitialization()：应用后置处理器的BeforeInitialization

3.6.3.3、invokeInitMethods()：执行自定义的初始化方法

3.6.3.4、applyBeanPostProcessorsAfterInitialization()：执行后置处理器的postProcessAfterInitialization()

3.6.4、BeanPostProcessor(AnnotationAwareAspectJAutoProxyCreator)

3.7、把BeanPostProcessor注册到BeanFactory中：

beanFactory.addBeanPostProcessor(postProcessor);

===以上是创建和注册AnnotationAwareAspectJAutoProxyCreator的过程===

4、finishBeanFactoryInitialization(beanFactory);完成BeanFactory初始话工作，创建剩下的单实例bean

4.1、编译获取容器中所有的bean，依次创建对象getBean(beanName);

getBean->doGetBean()->getSingleton()

4.2、创建bean

【AnnotationAwareAspectJAutoProxyCreator在所有bean创建之前会有一个拦截，InstantiationAwareBeanPostProcessor，会调用postProcessBeforeInstantiation()】

4.2.1、先从缓存中获取当前bean，如果能获取到，说明bean是之前被创建过直接使用，否则再创建；只要创建好的bean都会被缓存起来

4.2.2、createBean(); 创建bean; AnnotationAwareAspectJAutoProxyCreator会在任何bean创建之前尝试返回bean的实例

【BeanPostProcessor是在Bean对象创建完成初始化前后调用的】

【InstantiationAwareBeanPostProcessor是在创建Bean实例之前先尝试用后置处理器返回对象的】

4.2.2.1、resolveBeforeInstantiation(beanName, mbdToUse); 解析BeforeInstantiation

希望后置处理器在次能返回一个代理对象，如果不能就继续

4.2.2.1.1、后置处理器先尝试返回对象；

bean=applyBeanPostProcessorsBeforeInstantiation()

拿到所有后置处理器，如果是InstanttiationAwareBeanPostProcessor，就执行postProcessBeforeInstantiation

if (bean != null) {

bean = applyBeanPostProcessorsAfterInitialization(bean, beanName);

}

4.2.2.2、doCreateBean(beanName, mbdToUse, args); 真正地去创建一个bean实例；和3.6流程一致

processor的作用

AnnotationAwareAspectJAutoProxyCreator【InstanttiationAwareBeanPostProcessor】的作用：

1、每一个bean创建之前，调用postProcessBeforeInstantiation();

关心MathCalculator和LogAspect的创建

1.1、判断当前bean是否在advisedBeans中（保存了所有需要增强bean）

1.2、判断当前bean是否是基本类型Advice/PointCut/Adivsor/AopInfrastructureBean，或者是否为切面(@Aspect)

1.3、是否需要跳过

1.3.1、获取候选的增强器（切面里面的通知方法）【List candidateAdvisors】

每一个封装的通知方法的增强器是InstantiationModelAwarePointcutAdvisor;

判断每一个增强器是否是AspectJPointcutAdvisor类型的，返回true

1.3.2、永远返回false

2、创建对象

postProcessAfterInitialization;

return wrapIfNecessary(bean, beanName, cacheKey);//包装如果需要的情况下

2.1、获取当前bean的所有增强器（通知方法）Object[] specificInterceptors

2.1.1、找到能在当前bean使用的增强器（找哪些通知方法是需要切入当前bean方法的）

2.1.2、获取到能在bean使用的增强器。

2.1.3、给增强排序

2.2、保存当前bean在advisedBeans中

2.3、如果当前bean需要增强，创建当前bean的代理对象

2.3.1、获取所有增强器（通知方法）

2.3.2、保存到proxyFactory

2.3.3、创建代理对象，spring自动决定（jdk、cglib）

2.4、给容器中返回当前组件使用cglib增强了的代理对象

2.5、以后容器中获取到的就是这个组件的代理对象，执行目标方法的时候，代理对象就会执行通知方法的流程

3、目标方法的执行

容器中保存了组件的代理对象（cglib增强后的对象），这个对象里面保存了详细信息（比如增强器，目标对象，xxx）；

3.1、CglibAopProxy.intercept(); 拦截目标方法的执行

3.2、根据ProxyFactory对象获取将要执行的目标方法的拦截器链;

List

表达式名字	语法	用途
变量取值	${...}	获取请求域、session域、对象等值
选择变量	*{...}	获取上下文对象值
消息	#{...}	获取国际化等值
链接	@{...}	生成链接
片段表达式	~{...}	jsp:include作用，引入公共页面片段

Order	Feature	Attributes
1	Fragment inclusion	th:insert th:replace
2	Fragment iteration	th:each
3	Conditional evaluation	th:if th:unless th:switch th:case
4	Local variable definition	th:object th:with
5	General attribute modification	th:attr th:attrprepend th:attrappend
6	Specific attribute modification	th:value th:href th:src ...
7	Text (tag body modification)	th:text th:utext
8	Fragment specification	th:fragment
9	Fragment removal	th:remove

方法	说明
assertEquals	判断两个对象或两个原始类型是否相等
assertNotEquals	判断两个对象或两个原始类型是否不相等
assertSame	判断两个对象引用是否指向同一个对象
assertNotSame	判断两个对象引用是否指向不同的对象
assertTrue	判断给定的布尔值是否为 true
assertFalse	判断给定的布尔值是否为 false
assertNull	判断给定的对象引用是否为 null
assertNotNull	判断给定的对象引用是否不为 null

日志框架	配置文件
Logback	logback-spring.xml
Log4j2	log4j2-spring.xml,log4j2.xml
JUL	logging.properties

运算符	描述	示例
+	相加
-	相减
*	相乘
/	相除
%	求余
++	自增
--	自减

词性	内容
关键字	select、from、where
标志符	id、name、age
操作符	=、>、<
常量	1、2

	redo log	binlog
日志类型	物理日志	逻辑日志
文件大小	大小固定	可通过参数max_binlog_size设置每个binlog文件的大小
实现方式	由innodb引擎层实现，不是所有引擎都有	由service层实现，所有引擎都可以使用
记录	采用循环写的方式记录，当写到结尾时，会回到开头循坏写日志	通过追加的方式记录，当文件大小大于给定值后，后续的日志会记录到新的文件上
适用场景	适用于崩溃恢复（crash-safe）	适用于主从复制和数据恢复

Session A	Session B	Session C
update t21 set id=sleep(50) where id=1;
	select * from t21 where id=2; (wait 50s)
		show processlist;

Session A	Session B
insert into t31 values(null, 1, 1); insert into t31 values(null, 2, 2); insert into t31 values(null, 3, 3); insert into t31 values(null, 4, 4);
	create table t32 like t31;
insert into t32 values(null, 5, 5);	insert into t32(c,d) select c,d from t31;

	Session A	Session B
T1	begin; select * from tem; (1,1)
		update tem set c=2 where id=1; begin; update tem set c=3 where id=1;
	select * from tem; (1,3) // 脏读

Session A	Session B
begin; update t3 set a=2 where id=1;
	update t3 set a=2 where id=1; (blocked)

Session A	Session B
begin; select * from t3 where id=1; # 返回 (1,2)
	update t3 set a=3 where id=1;
update t3 set a=3 where id=1; Query OK, 0 rows affected (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 0
select * from t3 where id=1; # 返回 (1,3)

Session A	Session B
begin; select * from t3 where id=1; # 返回 (1,2)
	update t3 set a=3 where id=1;
update t3 set a=3 where id=1 and a=3; Query OK, 0 rows affected (0.01 sec) Rows matched: 1 Changed: 0 Warnings: 0
select * from t3 where id=1; # 返回 (1,2)

Session A	Session B	Session C
select sleep(1) from t4;
	flush tables t4;
		select * from t4 where id=1;

Session A	Session B
start transaction with consistent snapshot;
	update t4 set c=c+1 where id=1; //执行一万次
select * from t4 where id=1;
select * from t4 where id=1 lock in share mode;

Session A	Session B
start transaction with consistent snapshot;
	delete from t1; call idata();
	explain select * from t1 where a between 10000 and 20000;
commit;

事务A	事务B
begin; update t set k=k+1 where id=1; update t set k=k+1 where id=2;
	begin; update t set k=k+2 where id=1;
commit;
	commit;

事务A	事务B
begin; update t set k=k+1 where id=1;	begin;
	update t set k=k+2 where id=2;
update t set k=k+1 where id=2;
commit;	update t set k=k+2 where id=1;
	commit;

	Session A	Session B	Session C
T1	begin; select * from t5 where d=5 for update; // Q1 result: (5,5,5)
T2		update t5 set d=5 where id=0;
T3	select * from t5 where d=5 for update; // Q2 result: (0,0,5), (5,5,5)
T4			insert into t5 values (1,1,5);
T5	select * from t5 where d=5 for update; // Q3 result: (0,0,5),(1,1,5),(5,5,5)
T6	commit;

Session A	Session B
begin; select * from t5 where c=7 lock in share mode;
	begin; select * from t5 where c=7 for update;

Session A	Session B
begin; select * from t5 where id=9 for update;
	begin; select * from t5 where id=9 for update;
	insert into t5 values (9,9,9); (block)
insert into t5 values (9,9,9); (error, Deadlock found)

Session A	Session B	Session C
begin; update t5 set d=d+1 where id=7;
	insert into t5 values(8,8,8); (blocked)
		update t5 set d=d+1 where id=10; (Query OK)

Session A	Session B	Session C
begin; select id from t5 where c=5 lock in share mode;
	update t5 set d=d+1 where id=5; (Query OK)
		insert into t5 values(7,7,7); (blocked)

Session A	Session B	Session C
begin; select * from t5 where id>=10 and id<11 for update;
	insert into t5 values(8,8,8); (Query OK) insert into t5 values(13,13,13); (blocked)
		update t5 set d=d+1 where id=15; (blocked)

Session A	Session B	Session C
begin; select * from t5 where c>=10 and c<11 for update;
	insert into t5 values(8,8,8); (blocked) insert into t5 values(13,13,13); (blocked)
		update t5 set d=d+1 where c=15; (blocked)

Session A	Session B	Session C
begin; select * from t5 where id>10 and id<=15 for update;
	update t5 set d=d+1 where id=20; (blocked)
		insert into t5 values(16,16,16); (blocked)

Session A	Session B	Session C
begin; delete from t5 where c=10;
	insert into t5 values(12,12,12); (blocked)
		update t5 set d=d+1 where c=15; (Query OK)

Session A	Session B
begin; delete from t5 where c=10 limit2;
	insert into t5 values(12,12,12); (Query OK)

Session A	Session B
begin; select id from t5 where c=10 lock in share mode;
	update t5 set d=d+1 where c=10; (blocked)
insert into t5 values(8,8,8); (Query OK)
	Deadlock found

Session A	Session B	Session C
begin; select * from t5 where c>=15 and c<=20 order by c desc lock in share mode;
	insert into t5 values(8,8,8); (blocked)
		insert into t5 values(11,11,11); (blocked)

Session A	Session B
insert into t41 values(10,10,10);
begin; insert into t41 values(11,10,10); (Duplicate entry '10' for key 'c')
	insert into t41 values(12,9,9); (blocked)

	Session A	Session B	Session C
T1	begin; insert into t41 values(null,5,5);
T2		insert into t41 values(null,5,5);	insert into t41 values(null,5,5);
T3	rollback;		(Deadlock found)

Session A	Session B
begin; select * from t5 where id>10 and id<15 for update;
	delete from t5 where id=10; (Query OK)
	insert into t5 values(10,10,10); (blocked)

Session A	Session B
begin; select c from t5 where c>5 lock in share mode;
	update t set c=1 where c=5; (Query OK)
	update t set c=5 where c=1; (blocked)

Session A	Session B
create table t7(id int primary key)engine=innodb; begin; select * from t7 where id>1 for update;
	insert into t7 values(2); (blocked)
show engine innodb status;